Displaying 10 results from an estimated 10 matches for "2.024".
Did you mean:
2.02
2010 Feb 04
1
Help....package "GPLOTS" will not install. Linux
Hello,
Apologies in advance if this is not the appropriate forum for this post.
My problem is I'm not able to install the package "GPLOTS". Below are
the outputs for the commands: sessionInfo() and
install.packages("gplots",dependencies=TRUE).
It seems the package "GDATA" is part of the problem but I'm not an
expert in this. The "GDATA" package
2011 Dec 21
1
Yum update woes (perl compression)
I have had very little problems with yum and it's updates, but this one
has me stumped (CentOS 5.4):
Loaded plugins: fastestmirror, priorities
Loading mirror speeds from cached hostfile
* base: mirrors.loosefoot.com
* extras: yum.singlehop.com
* rpmforge: apt.sw.be
* updates: mirrors.cmich.edu
Setting up Update Process
Resolving Dependencies
--> Running transaction check
2011 Jan 03
3
yum update troubles
Running yum update on CentOS 4.8 32 bit I keep getting this:
--> Running transaction check
--> Processing Dependency: perl(Compress::Raw::Zlib) = 2.024 for
package: perl-IO-Compress
--> Finished Dependency Resolution
Error: Missing Dependency: perl(Compress::Raw::Zlib) = 2.024 is needed
by package perl-IO-Compress
I try to uninstall perl-IO-Compress but something like 91 packages
depend
2010 Jun 10
2
Openwebmail dependency problem
Ok, I have to ask. I tried to yum install the latest openwebmail (from
the openwebmail repo), and got a transaction check error about a
conflict with some packages which are needed by amavisd and spamassassin
(packages originating from rpmforge, I think). Below is the yum output.
By googling I found a lot of descriptions of the problem, but no solution.
- Jussi
(...)
Resolving Dependencies
2010 Feb 16
2
priorities don't prevent other repos overwritting packages?
Either I've made a mistake in my configuration or else packages from
other repos can obsolete core packages
For example, I did a "yum update" on some rpmforge packages and saw this:
Installing:
perl-Date-Manip noarch 5.54-2.el5.rf rpmforge 210 k
replacing perl-DateManip.noarch 5.44-1.2.1
perl-IO-Compress noarch 2.024-1.el5.rf
2010 Sep 02
2
Issue with Perl and rpmforge - advice?
I have an old version of rkhunter installed on my CentOS 5 machine,
one I got from rpmforge.
In my most recent attempts to update this, I get the following errors in yum:
Resolving Dependencies
--> Running transaction check
---> Package perl-AnyEvent.noarch 0:5.240-1.el5.rf set to be updated
--> Processing Dependency: perl(JSON::XS) >= 2.2 for package: perl-AnyEvent
--> Processing
2017 Jul 07
2
[PATCH v2] v2v: docs: VDSM location of virt-v2v log file.
See this bug for background information:
https://bugzilla.redhat.com/show_bug.cgi?id=1350465
Thanks: Tomáš Golembiovský
---
v2v/virt-v2v.pod | 38 ++++++++++++++++++++++++++------------
1 file changed, 26 insertions(+), 12 deletions(-)
diff --git a/v2v/virt-v2v.pod b/v2v/virt-v2v.pod
index e68d75cf8..0943bf305 100644
--- a/v2v/virt-v2v.pod
+++ b/v2v/virt-v2v.pod
@@ -1909,18 +1909,32 @@ that
2017 Jul 07
3
[PATCH] v2v: docs: VDSM location of virt-v2v log file.
See this bug for background information:
https://bugzilla.redhat.com/show_bug.cgi?id=1350465
---
v2v/virt-v2v.pod | 39 +++++++++++++++++++++++++++------------
1 file changed, 27 insertions(+), 12 deletions(-)
diff --git a/v2v/virt-v2v.pod b/v2v/virt-v2v.pod
index e68d75cf8..93d1a9ecd 100644
--- a/v2v/virt-v2v.pod
+++ b/v2v/virt-v2v.pod
@@ -1909,18 +1909,33 @@ that guest through the RHV-M UI,
2017 Jun 27
3
[PATCH] libvirt: disallow non-local connections (RHBZ#1347830)
If the connection is not local, paths of disks will refer to the remote
host, which were mistakenly handled as local paths (in the best case
failing to open a non-existing disk, and in the worst case opening a
different disk!).
In case the disks are remote resources like ssh or ceph, nothing
guarantees that the hostname can be reached from the local machine, or
even that it is actually the same on
2017 Jul 07
4
[PATCH v6 0/3] gobject: Remove gtk-doc (RHBZ#1465665).
Hopefully this time ...