Search Results

Search found 57 results on 3 pages for 'epel'.

Page 3/3 | < Previous Page | 1 2 3 

  • CentOS 5.6: How to resolve php53 RPM dependency conflict with php-mcrypt and php-common?

    - by Stefan Lasiewski
    We are running a CentOS 5.6 system, and want to install php53 with php-mcrypt. However, this introduces a dependency conflict between php-common & php53-common. Does anyone have a good workaround for this problem? host # yum install php-mcrypt Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * epel: linux.mirrors.es.net Setting up Install Process Resolving Dependencies --> Running transaction check ---> Package php-mcrypt.x86_64 0:5.1.6-15.el5.centos.1 set to be updated --> Processing Dependency: php-api = 20041225 for package: php-mcrypt --> Processing Dependency: php >= 5.1.6 for package: php-mcrypt --> Running transaction check ---> Package php.x86_64 0:5.1.6-27.el5_5.3 set to be updated --> Processing Dependency: php-cli = 5.1.6-27.el5_5.3 for package: php ---> Package php-common.x86_64 0:5.1.6-27.el5_5.3 set to be updated --> Running transaction check ---> Package php-cli.x86_64 0:5.1.6-27.el5_5.3 set to be updated --> Processing Conflict: php53-common conflicts php-common --> Finished Dependency Resolution php53-common-5.3.3-1.el5_6.1.x86_64 from installed has depsolving problems --> php53-common conflicts with php-common Error: php53-common conflicts with php-common You could try using --skip-broken to work around the problem You could try running: package-cleanup --problems package-cleanup --dupes rpm -Va --nofiles --nodigest This is apparently a known problem (See php-devel, Bug 700179 and Bug 695708) and this post at the CentOS forums, but there is no official fix yet.

    Read the article

  • How to install 64bit version of Mongodb

    - by slownage
    How can I install the 64bit (x86_64) version of MongoDB? I've specified in the 10gen.repo the 64bit: baseurl=http://downloads-distro.mongodb.org/repo/redhat/os/x86_64 But when I run: yum install mongo-10gen mongo-10gen-server It's the 32bit (see the i686) that it's set to be installed. Failed to set locale, defaulting to C Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * base: mirror.fdcservers.net * epel: mirror.steadfast.net * extras: mirror.fdcservers.net * rpmforge: mirror.rit.edu * updates: mirror.fdcservers.net 10gen | 951 B 00:00 Not using downloaded repomd.xml because it is older than what we have: Current : Tue Oct 30 15:55:02 2012 Downloaded: Tue Oct 30 15:54:51 2012 Setting up Install Process Resolving Dependencies --> Running transaction check ---> Package mongo-10gen.i686 0:2.2.1-mongodb_1 will be installed ---> Package mongo-10gen-server.i686 0:2.2.1-mongodb_1 will be installed --> Finished Dependency Resolution Dependencies Resolved ====================================================================================================================================================== Package Arch Version Repository Size ====================================================================================================================================================== Installing: mongo-10gen i686 2.2.1-mongodb_1 10gen 42 M mongo-10gen-server i686 2.2.1-mongodb_1 10gen 6.5 M Transaction Summary ====================================================================================================================================================== Install 2 Package(s) Total download size: 48 M Installed size: 118 M I think I know why it want's to install the 32bit version: the first time I've made the 10gen.repo file I had in there the 32bit link specified, and installed the 32bit, which later I've deleted. Maybe something has been cached. Could someone help me out with this.

    Read the article

  • yum trying to install el5 when I am on el6

    - by giorgio79
    When I run the following yum command I get this error: Package: git-1.7.10.1-1.el5.rf.x86_64 (rpmforge) Requires: libcurl.so.3()(64bit)" I read that this error is due to running an el5 rpmforge or having some el5 installed packages. How can I solve this problem? $ yum install git Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * base: centos.kiewel-online.ch * epel: fedora.kiewel-online.ch * extras: centos.kiewel-online.ch * rpmforge: mirror.de.leaseweb.net * updates: centos.kiewel-online.ch Setting up Install Process Resolving Dependencies --> Running transaction check ---> Package git.x86_64 0:1.7.10.1-1.el5.rf will be installed --> Processing Dependency: perl-Git = 1.7.10.1-1.el5.rf for package: git-1.7.10.1-1.el5.rf.x86_64 --> Processing Dependency: perl(Git) for package: git-1.7.10.1-1.el5.rf.x86_64 --> Processing Dependency: libexpat.so.0()(64bit) for package: git-1.7.10.1-1.el5.rf.x86_64 --> Processing Dependency: libcurl.so.3()(64bit) for package: git-1.7.10.1-1.el5.rf.x86_64 --> Running transaction check ---> Package compat-expat1.x86_64 0:1.95.8-8.el6 will be installed ---> Package git.x86_64 0:1.7.10.1-1.el5.rf will be installed --> Processing Dependency: libcurl.so.3()(64bit) for package: git-1.7.10.1-1.el5.rf.x86_64 ---> Package perl-Git.x86_64 0:1.7.10.1-1.el5.rf will be installed --> Finished Dependency Resolution Error: Package: git-1.7.10.1-1.el5.rf.x86_64 (rpmforge) Requires: libcurl.so.3()(64bit) You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest

    Read the article

  • Veewee, Vagrant, Puppet, Erlang and RabbitMQ

    - by Tobias
    I am kinda stuck with a problem I am trying to wrap my head around for days now. Here is what I am doing: By using Veewee, I am creating a VirtualBox image and then I create a Vagrant box from it. See here, here Finally I run puppet from Vagrant to install RabbitMQ, see here. Veewee, Vagrant and VirtualBox all run on MacOS X 10.7.4. The vagrant box itself is CentOS 6.2. This worked fine for quite some time until I was recreating the VirtualBox image a couple of days ago. During installation of the rabbitmq-plugins during my puppet run I now get the following error: /Stage[main]/Rabbitmq/Exec[rabbitmq-plugins]/returns: erlexec: HOME must be set My RabbitMQ puppet configuration can be found on my GitHub repo for that project, but here is the most important part: $version = "2.8.7" $url = "http://www.rabbitmq.com/releases/rabbitmq-server/v${version}/rabbitmq-server-${version}-1.noarch.rpm" package{"erlang": ensure => "present", } package{"rabbitmq-server": provider => "rpm", source => $url, require => Package["erlang"] } exec{"rabbitmq-plugins": path => "/usr/bin:/usr/sbin:/bin", command => "rabbitmq-plugins enable rabbitmq_management", require => Package["rabbitmq-server"] } My additional repositories, e.g. epel, are defined in veewees postinstall.sh right at the top of the file. Finally, this is what I get when I do '/etc/init.d/rabbitmq-server status' [{pid,2834}, {running_applications,[{rabbit,"RabbitMQ","2.8.7"}, {ssl,"Erlang/OTP SSL application","4.1.6"}, {public_key,"Public key infrastructure","0.13"}, {crypto,"CRYPTO version 2","2.0.4"}, {mnesia,"MNESIA CXC 138 12","4.5"}, {os_mon,"CPO CXC 138 46","2.2.7"}, {sasl,"SASL CXC 138 11","2.1.10"}, {stdlib,"ERTS CXC 138 10","1.17.5"}, {kernel,"ERTS CXC 138 10","2.14.5"}]}, {os,{unix,linux}}, {erlang_version,"Erlang R14B04 (erts-5.8.5) [source] [64-bit] [rq:1] [async-threads:30] [kernel-poll:true]\n"}, {memory,[{total,24993120}, {processes,10328496}, {processes_used,10321296}, {system,14664624}, {atom,1175905}, {atom_used,1143841}, {binary,17192}, {code,11416020}, {ets,766168}]}, {vm_memory_high_watermark,0.4}, {vm_memory_limit,205851852}, {disk_free_limit,1000000000}, {disk_free,7089795072}, {file_descriptors,[{total_limit,924}, {total_used,4}, {sockets_limit,829}, {sockets_used,2}]}, {processes,[{limit,1048576},{used,131}]}, {run_queue,0}, {uptime,6}] Sources in the web suggest, that I have to set HOME. Of course I was logging into the box if HOME was set, for user vagrant it was '/home/vagrant' and for root it was 'root'. As always, any hints/ideas/suggestions/assumptions are more than welcome. Thanks a lot! Cheers, Tobi

    Read the article

  • StrongSwan + xl2tpd client timeout between 2-5 minutes

    - by Howard Guo
    I run CentOS 6.4 on Amazon EC2, using xl2tpd-1.3.1 from EPEL repository together with StrongSwan 5.0.4. I setup a simple IPSec connection: conn l2tp type=transport keyexchange=ikev1 rekey=no authby=psk leftsubnet=0.0.0.0/0 rightsubnet=0.0.0.0/0 compress=yes auto=add And here is xl2tpd.conf: [global] ipsec saref = yes [lns default] ip range = 192.168.0.2-192.168.0.250 local ip = 192.168.0.1 ppp debug = yes pppoptfile = /etc/ppp/options.xl2tpd length bit = yes Here is options.xl2tpd: ms-dns 8.8.4.4 auth lock debug proxyarp There is only one client - Android 4.2 Android connects successfully: Oct 27 19:45:02 ip-172-31-17-30 xl2tpd[2706]: Connection established to x.x.x.x, 59578. Local: 18934, Remote: 29291 (ref=0/0). LNS session is 'default' Oct 27 19:45:02 ip-172-31-17-30 xl2tpd[2706]: Call established with x.x.x.x, Local: 36452, Remote: 29845, Serial: -1369754322 Oct 27 19:45:02 ip-172-31-17-30 pppd[2709]: pppd 2.4.5 started by howard, uid 0 Oct 27 19:45:02 ip-172-31-17-30 pppd[2709]: Using interface ppp0 Oct 27 19:45:02 ip-172-31-17-30 pppd[2709]: Connect: ppp0 <--> /dev/pts/0 Oct 27 19:45:02 ip-172-31-17-30 pppd[2709]: peer from calling number x.x.x.x authorized Oct 27 19:45:02 ip-172-31-17-30 pppd[2709]: Deflate (15) compression enabled Oct 27 19:45:03 ip-172-31-17-30 pppd[2709]: Cannot determine ethernet address for proxy ARP Oct 27 19:45:03 ip-172-31-17-30 pppd[2709]: local IP address 192.168.0.1 Oct 27 19:45:03 ip-172-31-17-30 pppd[2709]: remote IP address 192.168.0.2 Oct 27 19:45:03 ip-172-31-17-30 charon: 06[KNL] 192.168.0.1 appeared on ppp0 Oct 27 19:45:03 ip-172-31-17-30 charon: 06[KNL] 192.168.0.1 disappeared from ppp0 Oct 27 19:45:03 ip-172-31-17-30 charon: 06[KNL] 192.168.0.1 appeared on ppp0 Oct 27 19:45:03 ip-172-31-17-30 charon: 06[KNL] interface ppp0 activated In the meanwhile, Internet works perfectly on the Android client, the VPN connection is stable and fast. However, it always happens that within 2-5 minutes after the connection is established: Oct 27 19:47:07 ip-172-31-17-30 xl2tpd[2706]: Maximum retries exceeded for tunnel 18934. Closing. Oct 27 19:47:07 ip-172-31-17-30 xl2tpd[2706]: Connection 29291 closed to 95.91.227.224, port 59578 (Timeout) Oct 27 19:47:07 ip-172-31-17-30 charon: 06[KNL] interface ppp0 deactivated Oct 27 19:47:07 ip-172-31-17-30 charon: 06[KNL] interface ppp0 deleted Then the VPN connection is broken. So what might have gone wrong? The same L2TP service works flawlessly on iOS 7, MacOS 10.8, and Windows 7, there is no disconnection issue on those OSes. Thank you!

    Read the article

  • Need help with yum,python and php in CentOS. (I made a complete mess!)

    - by pek
    a while back I wanted to install some plugins for Trac but it required python 2.5 I tried installing it (I don't remember how) and the only thing I managed was to have two versions of python (2.4 and 2.5). Trac still uses the old version but the console uses 2.5 (python -V = Python 2.5.2). Anyway, the problem is not python, the problem is yum (which uses python). I am trying to upgrade my PHP version from 5.1.x to 5.2.x. I tried following this tutorial but when I reach the step with yum I get this error: >[root@XXX]# yum update Loading "installonlyn" plugin Setting up Update Process Setting up repositories Reading repository metadata in from local files Traceback (most recent call last): File "/usr/bin/yum", line 29, in ? yummain.main(sys.argv[1:]) File "/usr/share/yum-cli/yummain.py", line 94, in main result, resultmsgs = base.doCommands() File "/usr/share/yum-cli/cli.py", line 381, in doCommands return self.yum_cli_commands[self.basecmd].doCommand(self, self.basecmd, self.extcmds) File "/usr/share/yum-cli/yumcommands.py", line 150, in doCommand return base.updatePkgs(extcmds) File "/usr/share/yum-cli/cli.py", line 672, in updatePkgs self.doRepoSetup() File "/usr/share/yum-cli/cli.py", line 109, in doRepoSetup self.doSackSetup(thisrepo=thisrepo) File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 338, in doSackSetup self.repos.populateSack(which=repos) File "/usr/lib/python2.4/site-packages/yum/repos.py", line 200, in populateSack sack.populate(repo, with, callback, cacheonly) File "/usr/lib/python2.4/site-packages/yum/yumRepo.py", line 91, in populate dobj = repo.cacheHandler.getPrimary(xml, csum) File "/usr/lib/python2.4/site-packages/yum/sqlitecache.py", line 100, in getPrimary return self._getbase(location, checksum, 'primary') File "/usr/lib/python2.4/site-packages/yum/sqlitecache.py", line 86, in _getbase (db, dbchecksum) = self.getDatabase(location, metadatatype) File "/usr/lib/python2.4/site-packages/yum/sqlitecache.py", line 82, in getDatabase db = self.makeSqliteCacheFile(filename,cachetype) File "/usr/lib/python2.4/site-packages/yum/sqlitecache.py", line 245, in makeSqliteCacheFile self.createTablesPrimary(db) File "/usr/lib/python2.4/site-packages/yum/sqlitecache.py", line 165, in createTablesPrimary cur.execute(q) File "/usr/lib/python2.4/site-packages/sqlite/main.py", line 244, in execute self.rs = self.con.db.execute(SQL) _sqlite.DatabaseError: near "release": syntax error Any help? Thank you. Update OK, so I've managed to update yum hoping it would solve my problems but now I get a slightly different version of the same error: [root@XXX]# yum -y update Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * addons: mirror.skiplink.com * base: www.gtlib.gatech.edu * epel: mirrors.tummy.com * extras: yum.singlehop.com * updates: centos-distro.cavecreek.net (process:30840): GLib-CRITICAL **: g_timer_stop: assertion `timer != NULL' failed (process:30840): GLib-CRITICAL **: g_timer_destroy: assertion `timer != NULL' failed Traceback (most recent call last): File "/usr/bin/yum", line 29, in ? yummain.user_main(sys.argv[1:], exit_code=True) File "/usr/share/yum-cli/yummain.py", line 309, in user_main errcode = main(args) File "/usr/share/yum-cli/yummain.py", line 178, in main result, resultmsgs = base.doCommands() File "/usr/share/yum-cli/cli.py", line 345, in doCommands self._getTs(needTsRemove) File "/usr/lib/python2.4/site-packages/yum/depsolve.py", line 101, in _getTs self._getTsInfo(remove_only) File "/usr/lib/python2.4/site-packages/yum/depsolve.py", line 112, in _getTsInfo pkgSack = self.pkgSack File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 661, in <lambda> pkgSack = property(fget=lambda self: self._getSacks(), File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 501, in _getSacks self.repos.populateSack(which=repos) File "/usr/lib/python2.4/site-packages/yum/repos.py", line 260, in populateSack sack.populate(repo, mdtype, callback, cacheonly) File "/usr/lib/python2.4/site-packages/yum/yumRepo.py", line 190, in populate dobj = repo_cache_function(xml, csum) File "/usr/lib/python2.4/site-packages/sqlitecachec.py", line 42, in getPrimary self.repoid)) TypeError: Can not create packages table: near "release": syntax error I'm guessing that this "release" thing has something to do with a repository, but I didn't find anything... I went to the sqlitecachec.py at line 42 which writes (line numbers added for convenience): 39: return self.open_database(_sqlitecache.update_primary(location, 40: checksum, 41: self.callback, 42: self.repoid)) Update 2 I think I found the problem. This post suggests that the problem is sqlite and not yum. The version of sqlite I have installed is 3.6.10 but I have no idea which version does python 2.4 uses. ld.so.config contains the following: include ld.so.conf.d/*.conf /usr/local/lib In folder /usr/local/lib I find a symbolic link named libsqlite3.so that points to libsqlite3.so.0.8.6 WHAT IS HAPPENING??????? :S

    Read the article

  • CentOS 6 LEMP update - dependency error issue

    - by Latheesan Kanes
    I have setup a LEMP server following the guide Install Nginx/PHP-FPM on Fedora 20/19, CentOS/RHEL 6.5/5.10. It's been a while since I did the setup, so I wanted to grab the latest updates from REMI repository. I ran the following command: yum --enablerepo=remi,remi-php55 update I now get these dependency related errors: # yum --enablerepo=remi update Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * base: mirror.nl.leaseweb.net * epel: mirror.1000mbps.com * extras: mirror.nl.leaseweb.net * remi: remi.schlundtech.de * updates: centos.mirror1.spango.com Setting up Update Process Resolving Dependencies --> Running transaction check ---> Package chkconfig.x86_64 0:1.3.49.3-2.el6 will be updated ---> Package chkconfig.x86_64 0:1.3.49.3-2.el6_4.1 will be an update ---> Package glibc.x86_64 0:2.12-1.107.el6_4.4 will be updated ---> Package glibc.x86_64 0:2.12-1.107.el6_4.5 will be an update ---> Package glibc-common.x86_64 0:2.12-1.107.el6_4.4 will be updated ---> Package glibc-common.x86_64 0:2.12-1.107.el6_4.5 will be an update ---> Package gnupg2.x86_64 0:2.0.14-4.el6 will be updated ---> Package gnupg2.x86_64 0:2.0.14-6.el6_4 will be an update ---> Package iputils.x86_64 0:20071127-17.el6_4 will be updated ---> Package iputils.x86_64 0:20071127-17.el6_4.2 will be an update ---> Package kernel.x86_64 0:2.6.32-358.23.2.el6 will be installed ---> Package kernel-firmware.noarch 0:2.6.32-358.18.1.el6 will be updated ---> Package kernel-firmware.noarch 0:2.6.32-358.23.2.el6 will be an update ---> Package libgcrypt.x86_64 0:1.4.5-9.el6_2.2 will be updated ---> Package libgcrypt.x86_64 0:1.4.5-11.el6_4 will be an update ---> Package mysql-libs.x86_64 0:5.1.69-1.el6_4 will be updated --> Processing Dependency: libmysqlclient.so.16()(64bit) for package: 2:postfix-2.6.6-2.2.el6_1.x86_64 --> Processing Dependency: libmysqlclient.so.16(libmysqlclient_16)(64bit) for package: 2:postfix-2.6.6-2.2.el6_1.x86_64 ---> Package mysql-libs.x86_64 0:5.5.34-1.el6.remi will be an update ---> Package nginx.x86_64 0:1.4.2-1.el6.ngx will be updated ---> Package nginx.x86_64 0:1.4.3-1.el6.ngx will be an update ---> Package php-pear.noarch 1:1.9.4-20.el6.remi will be updated ---> Package php-pear.noarch 1:1.9.4-23.el6.remi will be an update ---> Package php-pecl-jsonc.x86_64 0:1.3.2-1.el6.remi.1 will be updated ---> Package php-pecl-jsonc.x86_64 0:1.3.2-2.el6.remi will be an update --> Processing Dependency: php(zend-abi) = 20100525-x86-64 for package: php-pecl-jsonc-1.3.2-2.el6.remi.x86_64 --> Processing Dependency: php(api) = 20100412-x86-64 for package: php-pecl-jsonc-1.3.2-2.el6.remi.x86_64 ---> Package php-pecl-mongo.x86_64 0:1.4.3-1.el6.remi.1 will be updated ---> Package php-pecl-mongo.x86_64 0:1.4.4-1.el6.remi will be an update --> Processing Dependency: php(zend-abi) = 20100525-x86-64 for package: php-pecl-mongo-1.4.4-1.el6.remi.x86_64 --> Processing Dependency: php(api) = 20100412-x86-64 for package: php-pecl-mongo-1.4.4-1.el6.remi.x86_64 ---> Package php-pecl-sqlite.x86_64 0:2.0.0-0.3.svn313074.el6.remi.5 will be updated ---> Package php-pecl-sqlite.x86_64 0:2.0.0-0.4.svn332053.el6.remi.5.4 will be an update --> Processing Dependency: php(zend-abi) = 20100525-x86-64 for package: php-pecl-sqlite-2.0.0-0.4.svn332053.el6.remi.5.4.x86_64 --> Processing Dependency: php(api) = 20100412-x86-64 for package: php-pecl-sqlite-2.0.0-0.4.svn332053.el6.remi.5.4.x86_64 ---> Package postgresql-libs.x86_64 0:8.4.13-1.el6_3 will be updated ---> Package postgresql-libs.x86_64 0:8.4.18-1.el6_4 will be an update ---> Package remi-release.noarch 0:6-2.el6.remi will be updated ---> Package remi-release.noarch 0:6.4-1.el6.remi will be an update ---> Package rsync.x86_64 0:3.0.6-9.el6 will be updated ---> Package rsync.x86_64 0:3.0.6-9.el6_4.1 will be an update ---> Package selinux-policy.noarch 0:3.7.19-195.el6_4.12 will be updated ---> Package selinux-policy.noarch 0:3.7.19-195.el6_4.18 will be an update ---> Package selinux-policy-targeted.noarch 0:3.7.19-195.el6_4.12 will be updated ---> Package selinux-policy-targeted.noarch 0:3.7.19-195.el6_4.18 will be an update ---> Package setup.noarch 0:2.8.14-20.el6 will be updated ---> Package setup.noarch 0:2.8.14-20.el6_4.1 will be an update ---> Package tzdata.noarch 0:2013c-2.el6 will be updated ---> Package tzdata.noarch 0:2013g-1.el6 will be an update ---> Package xinetd.x86_64 2:2.3.14-38.el6 will be updated ---> Package xinetd.x86_64 2:2.3.14-39.el6_4 will be an update --> Running transaction check ---> Package compat-mysql51.x86_64 0:5.1.54-1.el6.remi will be installed ---> Package php-pecl-jsonc.x86_64 0:1.3.2-2.el6.remi will be an update --> Processing Dependency: php(zend-abi) = 20100525-x86-64 for package: php-pecl-jsonc-1.3.2-2.el6.remi.x86_64 --> Processing Dependency: php(api) = 20100412-x86-64 for package: php-pecl-jsonc-1.3.2-2.el6.remi.x86_64 ---> Package php-pecl-mongo.x86_64 0:1.4.4-1.el6.remi will be an update --> Processing Dependency: php(zend-abi) = 20100525-x86-64 for package: php-pecl-mongo-1.4.4-1.el6.remi.x86_64 --> Processing Dependency: php(api) = 20100412-x86-64 for package: php-pecl-mongo-1.4.4-1.el6.remi.x86_64 ---> Package php-pecl-sqlite.x86_64 0:2.0.0-0.4.svn332053.el6.remi.5.4 will be an update --> Processing Dependency: php(zend-abi) = 20100525-x86-64 for package: php-pecl-sqlite-2.0.0-0.4.svn332053.el6.remi.5.4.x86_64 --> Processing Dependency: php(api) = 20100412-x86-64 for package: php-pecl-sqlite-2.0.0-0.4.svn332053.el6.remi.5.4.x86_64 --> Finished Dependency Resolution Error: Package: php-pecl-jsonc-1.3.2-2.el6.remi.x86_64 (remi) Requires: php(zend-abi) = 20100525-x86-64 Installed: php-common-5.5.4-1.el6.remi.x86_64 (@remi-test) php(zend-abi) = 20121212-64 Available: php-common-5.3.3-22.el6.x86_64 (base) php(zend-abi) = 20090626 Available: php-common-5.3.3-23.el6_4.x86_64 (updates) php(zend-abi) = 20090626 Available: php-common-5.4.21-1.el6.remi.x86_64 (remi) php(zend-abi) = 20100525-x86-64 Available: php-common-5.4.21-2.el6.remi.x86_64 (remi) php(zend-abi) = 20100525-x86-64 Error: Package: php-pecl-mongo-1.4.4-1.el6.remi.x86_64 (remi) Requires: php(zend-abi) = 20100525-x86-64 Installed: php-common-5.5.4-1.el6.remi.x86_64 (@remi-test) php(zend-abi) = 20121212-64 Available: php-common-5.3.3-22.el6.x86_64 (base) php(zend-abi) = 20090626 Available: php-common-5.3.3-23.el6_4.x86_64 (updates) php(zend-abi) = 20090626 Available: php-common-5.4.21-1.el6.remi.x86_64 (remi) php(zend-abi) = 20100525-x86-64 Available: php-common-5.4.21-2.el6.remi.x86_64 (remi) php(zend-abi) = 20100525-x86-64 Error: Package: php-pecl-jsonc-1.3.2-2.el6.remi.x86_64 (remi) Requires: php(api) = 20100412-x86-64 Installed: php-common-5.5.4-1.el6.remi.x86_64 (@remi-test) php(api) = 20121113-64 Available: php-common-5.3.3-22.el6.x86_64 (base) php(api) = 20090626 Available: php-common-5.3.3-23.el6_4.x86_64 (updates) php(api) = 20090626 Available: php-common-5.4.21-1.el6.remi.x86_64 (remi) php(api) = 20100412-x86-64 Available: php-common-5.4.21-2.el6.remi.x86_64 (remi) php(api) = 20100412-x86-64 Error: Package: php-pecl-sqlite-2.0.0-0.4.svn332053.el6.remi.5.4.x86_64 (remi) Requires: php(zend-abi) = 20100525-x86-64 Installed: php-common-5.5.4-1.el6.remi.x86_64 (@remi-test) php(zend-abi) = 20121212-64 Available: php-common-5.3.3-22.el6.x86_64 (base) php(zend-abi) = 20090626 Available: php-common-5.3.3-23.el6_4.x86_64 (updates) php(zend-abi) = 20090626 Available: php-common-5.4.21-1.el6.remi.x86_64 (remi) php(zend-abi) = 20100525-x86-64 Available: php-common-5.4.21-2.el6.remi.x86_64 (remi) php(zend-abi) = 20100525-x86-64 Error: Package: php-pecl-mongo-1.4.4-1.el6.remi.x86_64 (remi) Requires: php(api) = 20100412-x86-64 Installed: php-common-5.5.4-1.el6.remi.x86_64 (@remi-test) php(api) = 20121113-64 Available: php-common-5.3.3-22.el6.x86_64 (base) php(api) = 20090626 Available: php-common-5.3.3-23.el6_4.x86_64 (updates) php(api) = 20090626 Available: php-common-5.4.21-1.el6.remi.x86_64 (remi) php(api) = 20100412-x86-64 Available: php-common-5.4.21-2.el6.remi.x86_64 (remi) php(api) = 20100412-x86-64 Error: Package: php-pecl-sqlite-2.0.0-0.4.svn332053.el6.remi.5.4.x86_64 (remi) Requires: php(api) = 20100412-x86-64 Installed: php-common-5.5.4-1.el6.remi.x86_64 (@remi-test) php(api) = 20121113-64 Available: php-common-5.3.3-22.el6.x86_64 (base) php(api) = 20090626 Available: php-common-5.3.3-23.el6_4.x86_64 (updates) php(api) = 20090626 Available: php-common-5.4.21-1.el6.remi.x86_64 (remi) php(api) = 20100412-x86-64 Available: php-common-5.4.21-2.el6.remi.x86_64 (remi) php(api) = 20100412-x86-64 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest Any idea how to solve these errors? Am I missing a package? or is this a bug?

    Read the article

< Previous Page | 1 2 3