RPM package conflict between remi-safe and mariadb repo - repository

I am running Centos 7 with additional repositories remi-safe and mariaDB-10.5.
Everything worked fine for several months, now I get a package conflict when running yum update:
Error: Package: libzip5-1.8.0-2.el7.remi.x86_64 (remi-safe)
Required: libzstd(x86-64) >= 1.3.6
Available: libzstd-1.3.4-1.el7.x86_64 (mariadb-main)
libzstd(x86-64) = 1.3.4-1.el7
Error: Package: libzip5-1.8.0-2.el7.remi.x86_64 (remi-safe)
Required: libzstd(x86-64) >= 1.3.6
Install: libzstd-1.3.4-1.el7.x86_64 (mariadb-main)
libzstd(x86-64) = 1.3.4-1.el7
I tried to solve this by setting priorities to the yum repos (I gave 1 to MariaDB, 2 to Remi, 3 to Centos Base packages and 4 to EPEL) but this did not solve the issue.
How could I get remi-safe and mariadb-10.5 to live on the system again without quarreling?

EPEL have zstd 1.5.0, so you must use this one
So should either disable priority plugin or configure it properly, with higher priority for base and EPEL repository, higher priority means lower value.
Notice that mariadb 10.5 is available in official CentOS SCLo repository, which is probably better integrated to system.

Related

CentOs 7 cant install mod_wsgi

I am trying to get a server up and running to run python scripts (Django framework) and such by using the mod_wsgi apache module to handle the scripts, however, it's not playing ball and I don't know enough to figure out what's happening or what I'm doing wrong.
I have been unable to come right using the YUM installer. So far, this is the output:
# sudo yum install mod_wsgi
Loaded plugins: fastestmirror, universal-hooks
Loading mirror speeds from cached hostfile
* EA4: 169.255.59.74
* cpanel-addons-production-feed: 169.255.59.74
* base: mirror.wiru.co.za
* epel: fedora.mirror.ac.za
* extras: mirror.wiru.co.za
* ius: mirrors.ircam.fr
* updates: mirror.wiru.co.za
* webtatic: uk.repo.webtatic.com
Resolving Dependencies
--> Running transaction check
---> Package mod_wsgi.x86_64 0:3.4-12.el7_0 will be installed
--> Processing Dependency: httpd-mmn = 20120211x8664 for package:
mod_wsgi-3.4-12.el7_0.x86_64
--> Finished Dependency Resolution
Error: Package: mod_wsgi-3.4-12.el7_0.x86_64 (base)
Requires: httpd-mmn = 20120211x8664
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest
The first thing that jumped out is the dependency httpd which I tried (and failed) to install using yum. After this, I did some research and found out its an issue with cPanel and that apparently it prevents you from using Yum to install Apache modules and everywhere says I am supposed to use the interface but I have no idea how?
My goal is to figure out how I'm 'supposed' to be loading these modules to get around these obstacles and get my server going. Someone, please help!
I am running:
CentOs 7.5
Apache 2.4.34
EasyApache 4
cPanel 7.40
PHP 5.6.38
On a CentOS 7.5 machine, I updated httpd (Apache) using yum to 2.4.6-80.el7.centos.1. Not exactly sure what your situation is with your pre-installed httpd version 2.4.34. Like I said in my comment above, I only trust versions of software available though yum. Your version is above the standard version so you could experience unexpected results.
Updated:
httpd.i686 0:2.4.6-80.el7.centos.1
Dependency Updated:
httpd-devel.i686 0:2.4.6-80.el7.centos.1
httpd-manual.noarch 0:2.4.6-80.el7.centos.1
httpd-tools.i686 0:2.4.6-80.el7.centos.1
mod_ldap.i686 0:2.4.6-80.el7.centos.1
mod_ssl.i686 1:2.4.6-80.el7.centos.1
After upgrading httpd, I added mod_wsgi and it installed without any problems:
================================================================================
Package Arch Version Repository Size
================================================================================
Installing:
mod_wsgi i686 3.4-12.el7_0 base 75 k
Transaction Summary
================================================================================
Install 1 Package
Total download size: 75 k
Installed size: 187 k
Is this ok [y/d/N]: y
Downloading packages:
mod_wsgi-3.4-12.el7_0.i686.rpm | 75 kB 00:00
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Installing : mod_wsgi-3.4-12.el7_0.i686 1/1
Verifying : mod_wsgi-3.4-12.el7_0.i686 1/1
Installed:
mod_wsgi.i686 0:3.4-12.el7_0
Complete!
I guess the point I'm trying to make is that if you use version of software no available through yum you can experience unexpected results. I have been down this road before and I now use version of software only if they are available through yum.
The error you recieved: Requires: httpd-mmn = 20120211x8664 is for a package not yet available through yum. I performed a yum search on a CentOS 7.5 machine and it yields nothing available for httpd-mmn:
yum search httpd-mmn
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
Warning: No matches found for: httpd-mmn
No matches found
So, you would have to compile it yourself possibly to get your setup to work.

Phalcon 3 - Centos 7 Cpanel EasyApache 4 - php5.6

I am trying to install Phalcon with:
curl -s https://packagecloud.io/install/repositories/phalcon/stable/script.rpm.sh | sudo bash
yum install php56u-phalcon
but I get dependency errors:
Error: Package: php56u-phalcon-3.0.1-14.ius.el7.centos.x86_64 (phalcon_stable)
Requires: php56u-pdo(x86-64)
Error: Package: php56u-phalcon-3.0.1-14.ius.el7.centos.x86_64 (phalcon_stable)
Requires: php56u-common(x86-64)
Error: Package: php56u-phalcon-3.0.1-14.ius.el7.centos.x86_64 (phalcon_stable)
Requires: php56u(api) = 20131106
Error: Package: php56u-phalcon-3.0.1-14.ius.el7.centos.x86_64 (phalcon_stable)
Requires: php56u(zend-abi) = 20131226
These libraries are installed but with the modifier "ea-" of easy apache.
How I can install Phalcon 3 in Centos 7 cpanel easyapache 4?
Thanks in advance.
Seems like phalcon expecting you to have php56 from ius repository.
I've had same error, but because my php56 came from remi repo instead I had no modifier on php* packages, for example php-pdo package instead of php56u-pdo.
I've solved it this way:
yum install php-phalcon3
(can be php-phalcon2, php7-php-palcon3 and so on - see yum search phalcon)
In your case this probably won't help, because you have ea- modifier on php*.
Possibly somebody more experienced with yum could suggest how to solve this conflict. But you still have two more options:
compile phalcon.so from source code (described here: https://github.com/phalcon/cphalcon).
install php from ius Centos 7 repository.
UPD: I must add that I was unable to make phalcon (php-phalcon* from remi dedicated repos for php5.6 and php7) to work - I've got "child pid exit signal Segmentation fault".
As a general rule: your phalcon package should be from the same repo from which you've installed php and php-* packages(e.g. php-mysqlnd, php-pdo).
In my opinion, if you wnat to be sure that your library will work on particular machine the best way is to compile it on this or similar machine.

yum update on CentOS complains about "Multilib version problems" of "nss-softokn-freebl"

On last Friday morning, I tried a "yum update" on my CentOS laptop, and it reported this:
Loaded plugins: fastestmirror, langpacks, verify
Loading mirror speeds from cached hostfile
* base: repo1.dal.innoscale.net
* epel: fedora-epel.mirror.lstn.net
* extras: mirror.unl.edu
* nux-dextop: mirror.li.nux.ro
* rpmfusion-free-updates: mirror.us.leaseweb.net
* updates: mirror.spro.net
Resolving Dependencies
--> Running transaction check
---> Package nss-softokn-freebl.i686 0:3.16.2.3-13.el7_1 will be updated
---> Package nss-softokn-freebl.i686 0:3.16.2.3-14.2.el7_2 will be an update
---> Package python-ecdsa.noarch 0:0.11-3.el7.centos will be obsoleted
---> Package python2-ecdsa.noarch 0:0.13-4.el7 will be obsoleting
---> Package tzdata.noarch 0:2016c-1.el7 will be updated
---> Package tzdata.noarch 0:2016d-1.el7 will be an update
---> Package tzdata-java.noarch 0:2016c-1.el7 will be updated
---> Package tzdata-java.noarch 0:2016d-1.el7 will be an update
--> Finished Dependency Resolution
Error: Multilib version problems found. This often means that the root
cause is something else and multilib version checking is just
pointing out that there is a problem. Eg.:
1. You have an upgrade for nss-softokn-freebl which is missing some
dependency that another package requires. Yum is trying to
solve this by installing an older version of nss-softokn-freebl of the
different architecture. If you exclude the bad architecture
yum will tell you what the root cause is (which package
requires what). You can try redoing the upgrade with
--exclude nss-softokn-freebl.otherarch ... this should give you an error
message showing the root cause of the problem.
2. You have multiple architectures of nss-softokn-freebl installed, but
yum can only see an upgrade for one of those architectures.
If you don't want/need both architectures anymore then you
can remove the one with the missing update and everything
will work.
3. You have duplicate versions of nss-softokn-freebl installed already.
You can use "yum check" to get yum show these errors.
...you can also use --setopt=protected_multilib=false to remove
this checking, however this is almost never the correct thing to
do as something else is very likely to go wrong (often causing
much more problems).
Protected multilib versions: nss-softokn-freebl-3.16.2.3-14.2.el7_2.i686 != nss-softokn-freebl-3.16.2.3-13.el7_1.x86_64
I asked about this on #centos, and someone gave me some exploratory advice, but no real solution.
I experienced the very same issue on a Fedora 20 system (run in a docker container) when trying to install i686 development libraries. Reason were two not matching versions for x86_64 and i686, respectively.
Protected multilib versions: nss-softokn-freebl-3.19.1-1.0.fc20.i686 != nss-softokn-freebl-3.19.2-1.0.fc20.x86_64
For me it helped to call
yum distribution-synchronization
That automatically downgraded the x86_64 version. After that
I could install with
yum install nss-softokn-freebl.i686
and
yum list installed | grep nss-softokn-freebl
showed now:
nss-softokn-freebl.i686 3.19.1-1.0.fc20 #updates
nss-softokn-freebl.x86_64 3.19.1-1.0.fc20 #updates
Problem solved.

CentOS yum 'No package gnuradio available'

I'm installing GNU Radio and following the instruction here
But everytime I try to do sudo yum install gnuradio, it says
Loaded plugins: fastestmirror, refresh-packagekit, security
Loading mirror speeds from cached hostfile
* base: centos.mirror.cdnetworks.com
* extras: centos.mirror.cdnetworks.com
* updates: centos.mirror.cdnetworks.com
Setting up Install Process
No package gnuradio available.
Error: Nothing to do
It's a fresh installed CentOS 6.5 and I've never edited CentOS yum repository information. What's wrong with gnuradio? They've removed the package from yum repository?
In their website, they provide several ways to install it including PyBOMBS. But I prefer yum. Building from source is somewhat bothering me so it's the last thing I will try.
By default CentOS does not include all the repositories needed by gnuradio and its dependencies.
You additionally need to configure/add at least RPMForge and Epel for your CentOS.
References:
http://wiki.centos.org/AdditionalResources/Repositories/RPMForge#head-f0c3ecee3dbb407e4eed79a56ec0ae92d1398e01
http://www.rackspace.com/knowledge_center/article/installing-rhel-epel-repo-on-centos-5x-or-6x
This is what I was told, but I have not yet tested this so cannot say is is correct for sure.

Debian: How can I pull a single package with dependencies from another repository?

I am on debian etch and I want to pull subversion1.5.1 from testing though it is a production machine. I need to keep the risk minimal.
Any hints?
Just add the testing repository to your sources.list and pin the priority of the testing packages to a very low value:
Add the following to /etc/apt/preferences:
Package: *
Pin: release a=testing
Pin-Priority: 200
200 means that new packages in testing still override local packages that are not in stable (local is always 100), but not ones that are in the stable repo as well.
Read apt_preferences(5) for more information on pinning.
Then, you can install packages from testing by doing
$ apt-get install -t testing $some_package
but they won't be installed by normal upgrade operations or won't be the default when installed with apt.