Tag Info

New answers tagged

0

You can do this to upgrade your subversion : For CentOS/RHEL 7 Users: [WandiscoSVN] name=Wandisco SVN Repo baseurl=http://opensource.wandisco.com/centos/7/svn-1.8/RPMS/$basearch/ enabled=1 gpgcheck=0 For CentOS/RHEL 6 Users: [WandiscoSVN] name=Wandisco SVN Repo baseurl=http://opensource.wandisco.com/centos/6/svn-1.8/RPMS/$basearch/ ...


1

You need to enable the RHEL optional and/or extras channels. yum-config-manager --enable rhui-REGION-rhel-server-extras rhui-REGION-rhel-server-optional


2

Unless you're looking for some specific version a 3rd party package has been compiled against, it's called curl-devel in RHEL 5. yum install curl-devel # rpm -qpl curl-devel-7.15.5-17.el5_9.x86_64.rpm | grep libcurl /usr/lib64/libcurl.a /usr/lib64/libcurl.so /usr/lib64/pkgconfig/libcurl.pc /usr/share/man/man3/libcurl-easy.3.gz ...


0

The best command will be $ yum install epel-release and yum will get the correct rpm You can further run the below commands to fix the public key error. $ yum clean all $ yum makecache $ yum update


0

I considered the problem of if one changes the version of java being used with: alternatives --config java Then any hard coded JAVA_HOME is going to change (atleast it will on the Centos 6.6 I'm currently staring at). That is, there is no /usr/java. This doesn't seem like the best way (open to failure) but in the 10 mins I've spent on this it seems the ...


0

This is not meant to be a complete answer, but since until now nobody has provided reasons on why this isn't procedure CAN be a bad idea: Certain versions of packages rely on functions provided by external libraries. Those libraries change over time, and in that process possibly change their behavior or even completely remove functions. Moving from EL6 to ...


0

I usually get this when updating a 64-bit package that has the equivalent 32-bit package installed, but the 32-bit update package doesn't exist, perhaps because the 32-bit channel isn't subscribed, or maybe the current channel doesn't have updated 32-bit channels. If I don't need the 32-bit version, I remove it and then try the update.


1

Recommendation from RHN is to downgrade the packages: yum downgrade libgomp yum downgrade libstdc++ yum downgrade libgcc yum downgrade cpp Source: https://access.redhat.com/solutions/196103 (Answer visible to RHN subscribers)


0

I got it, and it was so simple! In order to resolve this issue, I had to disable SELinux and reboot the server. That's it.


0

Chances are pretty good that your corporate IT folks are signing their own certs (and intercepting all traffic, etc.). If you don't think they are evil, you could try adding ... sslverify=0 in /etc/yum.conf and then hopefully yum will "just work", though less securely.



Top 50 recent answers are included