[CentOS] ganglia failing dependency

2011-10-08 Thread Tim Dunphy
hello list,

 I'm trying to install ganglia-gmetad on centos 5.6. rrdtool is already 
installed and librrd is there. But for some reason when I go to install this 
package it doesn't see that it is.
[root@VIRTCENT11:/usr/local/src/ganglia-3.2.0] #yum install ganglia-gmetad
Loaded plugins: fastestmirror, security
Loading mirror speeds from cached hostfile
 * base: mirrors.lga7.us.voxel.net
 * epel: serverbeach1.fedoraproject.org
 * extras: mirror.umoss.org
 * rpmforge: fr2.rpmfind.net
 * updates: mirror.atlanticmetro.net
Excluding Packages in global exclude list
Finished
Setting up Install Process
Resolving Dependencies
-- Running transaction check
--- Package ganglia-gmetad.i386 0:3.0.7-1.el5 set to be updated
-- Processing Dependency: librrd.so.2 for package: ganglia-gmetad
-- Finished Dependency Resolution
ganglia-gmetad-3.0.7-1.el5.i386 from epel has depsolving problems
  -- Missing Dependency: librrd.so.2 is needed by package 
ganglia-gmetad-3.0.7-1.el5.i386 (epel)
Error: Missing Dependency: librrd.so.2 is needed by package 
ganglia-gmetad-3.0.7-1.el5.i386 (epel)
 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



But here are the required libraries:


[root@VIRTCENT11:/usr/local/src/ganglia-3.2.0] #locate librrd.so.2
/usr/lib/librrd.so.2
/usr/lib/librrd.so.2.0.13

Does anyone have any ideas on how to get past this point?

thanks!

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] ganglia failing dependency

2011-10-08 Thread John R Pierce
On 10/08/11 5:47 PM, Tim Dunphy wrote:
 [root@VIRTCENT11:/usr/local/src/ganglia-3.2.0] #locate librrd.so.2
 /usr/lib/librrd.so.2
 /usr/lib/librrd.so.2.0.13

 Does anyone have any ideas on how to get past this point?

it appears there are rrdtool's in both rpmforge and epel.  odds are, 
these aren't packaged in a compatible manner.  anyways, your ganglia 
stuff is from epel, so you probably should ask them.





-- 
john r pierceN 37, W 122
santa cruz ca mid-left coast

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] ganglia failing dependency

2011-10-08 Thread Ljubomir Ljubojevic
Vreme: 10/09/2011 02:56 AM, John R Pierce piše:
 On 10/08/11 5:47 PM, Tim Dunphy wrote:
 [root@VIRTCENT11:/usr/local/src/ganglia-3.2.0] #locate librrd.so.2
 /usr/lib/librrd.so.2
 /usr/lib/librrd.so.2.0.13

 Does anyone have any ideas on how to get past this point?

 it appears there are rrdtool's in both rpmforge and epel.  odds are,
 these aren't packaged in a compatible manner.  anyways, your ganglia
 stuff is from epel, so you probably should ask them.






Tim, remove rrdtool (you installed it from repoforge/rpmforge) and rum 
install for ganglia-gmetad. rrdtool will be automaticaly installed:

[root@kancelarija yum.repos.d]# yum install ganglia-gmetad
Loaded plugins: downloadonly, fastestmirror, priorities, refresh-packagekit
Loading mirror speeds from cached hostfile
1032 packages excluded due to repository priority protections
Setting up Install Process
Resolving Dependencies
-- Running transaction check
--- Package ganglia-gmetad.x86_64 0:3.1.7-3.el6 will be installed
-- Processing Dependency: ganglia = 3.1.7-3.el6 for package: 
ganglia-gmetad-3.1.7-3.el6.x86_64
-- Processing Dependency: librrd.so.4()(64bit) for package: 
ganglia-gmetad-3.1.7-3.el6.x86_64
-- Processing Dependency: libganglia-3.1.7.so.0()(64bit) for package: 
ganglia-gmetad-3.1.7-3.el6.x86_64
-- Processing Dependency: libconfuse.so.0()(64bit) for package: 
ganglia-gmetad-3.1.7-3.el6.x86_64
-- Running transaction check
--- Package ganglia.x86_64 0:3.1.7-3.el6 will be installed
--- Package libconfuse.x86_64 0:2.6-3.el6 will be installed
--- Package rrdtool.x86_64 0:1.3.8-6.el6 will be installed
-- Processing Dependency: dejavu-lgc-sans-mono-fonts for package: 
rrdtool-1.3.8-6.el6.x86_64
-- Running transaction check
--- Package dejavu-lgc-sans-mono-fonts.noarch 0:2.30-2.el6 will be 
installed
-- Finished Dependency Resolution

Dependencies Resolved

==
  Package  Arch Version 
Repository  Size
==
Installing:
  ganglia-gmetad   x86_64   3.1.7-3.el6 
plc-epel34 k
Installing for dependencies:
  dejavu-lgc-sans-mono-fonts   noarch   2.30-2.el6plc-os 
 393 k
  ganglia  x86_64   3.1.7-3.el6 
plc-epel   150 k
  libconfuse   x86_64   2.6-3.el6 
plc-epel76 k
  rrdtool  x86_64   1.3.8-6.el6   plc-os 
 293 k

Transaction Summary
==
Install   5 Package(s)

Total download size: 945 k
Installed size: 3.1 M
Is this ok [y/N]:


Also, install yum-plugin-priorities and setup priorites for all repos. I 
would use priority=1 for all main repos, priority=2 for EPEL, and 
priority=3 for Repoforge, ...

-- 

Ljubomir Ljubojevic
(Love is in the Air)
PL Computers
Serbia, Europe

Google is the Mother, Google is the Father, and traceroute is your
trusty Spiderman...
StarOS, Mikrotik and CentOS/RHEL/Linux consultant
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Ganglia

2010-06-18 Thread John Doe
From: John R. Dennison j...@gerdesas.com
 On Thu, Jun 17, 2010 at 08:09:11PM -0400, Whit Blauvelt wrote:
 I should care what you believe?
 Is this vitriol really necessary?

I think it is just a reaction to the I don't believe you at all, which some 
people would take as you are a liar...
That's the problem with internet communications.
The sender say things he would not say face to face, and the recipient does not 
know the mood of the sender.
Emoticons cannot completely solve it...  :/

JD


  
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Ganglia

2010-06-18 Thread Whit Blauvelt
On Thu, Jun 17, 2010 at 08:22:35PM -0500, John R. Dennison wrote:

   Is this vitriol really necessary?  I installed ganglia; not a 
   single conflict.

Why yes, John, it is. The fine man said outright he didn't believe my honest
account, accusing me of making something up when I was only giving the
facts. He was calling me a liar. He preferred to see my account as a lie so
as not to surrender his faith that Ganglia is a pure and perfect project.
Attitudes like that are dangerous in computing, since they lead to bugs not
being fixed.

   If you want shiny and new, why not do it properly and build
   rpms?

You installed without a conflict, good. Perhaps you were installing on a
32-bit system rather than a 64-bit? Perhaps your system didn't have some of
the packages already installed for other functionality that mine did? All I
can say is that, for my system, yum saw version conflicts that were
blockers.

As for properly, there are, as Larry Wall says, many ways to do it. It is
up to each project, as their first task, IMHO, to see to it that
./configure, make, make install works for their package, with proper,
documented flags, on standard Linux distros. Ganglia - a fine and valuable
project on the whole - has a broken make install. But it can be worked
around. Finding workarounds is often a sysadmins job. Sharing those
workarounds with the community is often how free software stays ahead of the
proprietary stuff. 

On the whole, this list is professional. I like that. But look,
./configure, make, make install is _always_ a proper option. Any serious
business will have need of building on occassional program with different
flags than the distro's default, whatever the distro. I often end up
building a few core applications that way, as do many other sysadmins in
serious business settings. If you don't need to, that's fine. Some
businesses can wear off-the-rack cloths. Others need tailored garments.

Regards,
Whit
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Ganglia

2010-06-18 Thread Whit Blauvelt
On Thu, Jun 17, 2010 at 08:10:29PM -0500, John R. Dennison wrote:
 On Thu, Jun 17, 2010 at 08:01:02PM -0400, Joshua Baker-LePain wrote:
  
  That being said, it's trivial to recompile the F13 RPM for 3.1.2 for 
  centos-5.
 
   And that would be the proper route to go instead of building
   from native source :)

To get 3.1.7? Disregarding that, I should jump through the hoops of
recompiling a F13 RPM rather than just compile from the tar? Why? Every
extra stage like that introduces the chance of incidental errors, of stuff
that doesn't translate precisely through that stage. I'm not doubting it
generally can work, just that there's anything proper about it. Generally
native source is the gold standard. The farther upstream you go, the better
the quality gets, the more bugs are fixed, and the more control you have
over how and where the stuff installs on your systems. 

There can be an argument that for some stuff that passes through RHEL the
extra attention adds some quality control (ignoring the counterexample of
the long history of RH manging kernels; they seem to have gotten better
about that lately), but stuff in EPEL? Really?

I'm not talking Linux from Scratch here - although I respect that project
immensely. I appreciate a solid distro as a foundation. CentOS is. But
claims that any distro is so perfect and complete that it's improper to
custom compile a few apps on its foundation - from the native source (with
all the connotations that natives are scarey and primitive) - should not
be well received if we want to continue to have open platforms.

Best,
Whit
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Ganglia

2010-06-18 Thread Nicolas Thierry-Mieg
Whit Blauvelt wrote:
 On Thu, Jun 17, 2010 at 08:22:35PM -0500, John R. Dennison wrote:
snip
  If you want shiny and new, why not do it properly and build
  rpms?

long snip
 On the whole, this list is professional. I like that. But look,
 ./configure, make, make install is _always_ a proper option. Any serious
 business will have need of building on occassional program with different
 flags than the distro's default, whatever the distro. I often end up
 building a few core applications that way, as do many other sysadmins in
 serious business settings. If you don't need to, that's fine. Some
 businesses can wear off-the-rack cloths. Others need tailored garments.

you didn't get it Whit, John was not saying stick to what's in the 
distro [or trusted 3rd party repos].
He was suggesting to build your own rpms when needed. This allows you to 
use whatever version, build flags, options etc, just like your 
configure-make-make install solution. But it has many advantages, 
including easier housekeeping and dep management, deploying to many 
systems, pushing new versions, etc
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Ganglia

2010-06-18 Thread Les Mikesell
Whit Blauvelt wrote:

 You installed without a conflict, good. Perhaps you were installing on a
 32-bit system rather than a 64-bit? Perhaps your system didn't have some of
 the packages already installed for other functionality that mine did? All I
 can say is that, for my system, yum saw version conflicts that were
 blockers.

That doesn't make any sense.  Yum pulls whatever it needs from the configured 
repos if you don't have them.  If yum sees conflicts on your system it is 
because you installed packages from somewhere other than the base and epel 
repos 
and thus shouldn't be blaming the package or packager.

 As for properly, there are, as Larry Wall says, many ways to do it.

Yes, but none of them involve setting up unexpected conflicts with the base or 
epel repository packages.

 It is
 up to each project, as their first task, IMHO, to see to it that
 ./configure, make, make install works for their package, with proper,
 documented flags, on standard Linux distros. Ganglia - a fine and valuable
 project on the whole - has a broken make install.

Did you mean to say it didn't run on your system?  Or that you didn't apply the 
changes in the rpm spec file before expecting it to work?

 On the whole, this list is professional. I like that. But look,
 ./configure, make, make install is _always_ a proper option.

If you are careful to keep the results in /usr/local or /opt, maybe.  Otherwise 
you'll likely overwrite something that should be managed. And call things 
broken 
that are your own fault.

-- 
   Les Mikesell
lesmikes...@gmail.com
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Ganglia

2010-06-18 Thread Whit Blauvelt
On Thu, Jun 17, 2010 at 08:19:46PM -0500, John R. Dennison wrote:

   I just tried a ganglia install from EPEL; absolutely no issues
   at all.  Perhaps if you'd bother to actually document these
   conflicts one of us might be able to help.  That is if we're
   still willing.

Now you're threatening to expel me from the community? For posting notes on
workarounds to get a useful package to work? What's this about? Ganglia's
working fine for me.

   I can't speak to your claims of 3.1.7 having bug fixes and
   the multicpu issue; but I saw no conflicts with EPEL's 3.0.7.

My claims? The project's own documents describe this stuff. You saw no
conflicts? Great. Not every bug shows up on every box. You believe one
instance of not seeing a bug means no on else will? That's Microsoft-style
quality control.

  If there were a good CentOS build of 3.1.7 I'd happily use it. But getting
  stuff from EPEL, which is essentially Redhat testing, is as silly as mixing
 
   Uh, you've confused EPEL and Fedora apparently.

Sorry. If that's confusion, I got it from instructions (several sets of
them) out on the web for installing Ganglia from EPEL, which referred to it
as a Fedora repository. 

   Gentoo is fine for a toy os.  Claiming Gentoo is enterprise is
   just silly.

No point in including a long list of serious enterprises which run on
Gentoo. You're in fanboi mode and it's not your team. Fine.

   Kids?  Heh.  17 years?  Heh.  You're a youngster.  Let me know
   when you've got 25+ years in the industry and then I might be
   impressed :)

I said I've been a Linux sysadmin since '93. I've been in the industry since
'82. Thanks for mistaking me for a youngster though!

Whit
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Ganglia

2010-06-18 Thread Les Mikesell
Whit Blauvelt wrote:
 On Thu, Jun 17, 2010 at 08:10:29PM -0500, John R. Dennison wrote:
 On Thu, Jun 17, 2010 at 08:01:02PM -0400, Joshua Baker-LePain wrote:
 That being said, it's trivial to recompile the F13 RPM for 3.1.2 for 
 centos-5.
  And that would be the proper route to go instead of building
  from native source :)
 
 To get 3.1.7? Disregarding that, I should jump through the hoops of
 recompiling a F13 RPM rather than just compile from the tar? Why?

Because rpm tracks all the files installed from packages, and yum understands 
the dependencies.  You've clearly broken that on your system.  And you probably 
have no idea how to verify that your tarball-installed files are still the same 
ones you installed or how to remove all of them cleanly.

 Every
 extra stage like that introduces the chance of incidental errors, of stuff
 that doesn't translate precisely through that stage. I'm not doubting it
 generally can work, just that there's anything proper about it. Generally
 native source is the gold standard. The farther upstream you go, the better
 the quality gets, the more bugs are fixed, and the more control you have
 over how and where the stuff installs on your systems. 

There's always a tradeoff between new code introducing new bugs and fixing old 
ones.  Fedora takes a different position in that tradeoff than RHEL/Centos and 
sometimes that's what you want for certain applications.  And if the src RPM 
will rebuild painlessly you get the advantage of rpm management for next to no 
extra work.  Plus you know someone else has at least run the code a time or 
two, 
something you don't know about the straight upstream source.

 There can be an argument that for some stuff that passes through RHEL the
 extra attention adds some quality control (ignoring the counterexample of
 the long history of RH manging kernels; they seem to have gotten better
 about that lately), but stuff in EPEL? Really?

One of EPEL's goals is to not overwrite or conflict with any base rpms.  They 
are't perfect, their idea of 'base' doesn't include centos extras, and their 
guidlines keep out some things you probably want, but in general they are 
pretty 
good and it is a very valuable thing to be able to install any of their 
packages 
without worrying about conflicts.  Other 3rd party repos don't make the same 
effort or intentionally update existing system libraries to meet their own 
goals.

 I'm not talking Linux from Scratch here - although I respect that project
 immensely. I appreciate a solid distro as a foundation. CentOS is. But
 claims that any distro is so perfect and complete that it's improper to
 custom compile a few apps on its foundation - from the native source (with
 all the connotations that natives are scarey and primitive) - should not
 be well received if we want to continue to have open platforms.

You need to think of rpm as a database with integrity rules - because that's 
what it is.  And think about what happens if you randomly scribble stuff in a 
database ignoring its rules - because that's what you are doing.  There are 
times you need to do some experimental things, but they should be kept out of 
the system area or you loose the advantage that package management tools 
provide.  Or you  should build your own rpms to incorporate the files into the 
system properly.

-- 
Les Mikesell
 lesmikes...@gmail.com


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Ganglia

2010-06-18 Thread Jerry McAllister
On Fri, Jun 18, 2010 at 08:14:02AM -0400, Whit Blauvelt wrote:

 On Thu, Jun 17, 2010 at 08:22:35PM -0500, John R. Dennison wrote:
 
  Is this vitriol really necessary?  I installed ganglia; not a 
  single conflict.
 
 Why yes, John, it is. The fine man said outright he didn't believe my honest
 account, accusing me of making something up when I was only giving the
 facts. He was calling me a liar. He preferred to see my account as a lie so
 as not to surrender his faith that Ganglia is a pure and perfect project.

there is a big difference in saying you don't believe a person's
information and calling them a liar.You may just be saying you
perceive things differently or maybe that the person doesn't understand
about which he is speaking.   He may be entirely truthful and still
not be believed.


jerry



 Attitudes like that are dangerous in computing, since they lead to bugs not
 being fixed.
 
  If you want shiny and new, why not do it properly and build
  rpms?
 
 You installed without a conflict, good. Perhaps you were installing on a
 32-bit system rather than a 64-bit? Perhaps your system didn't have some of
 the packages already installed for other functionality that mine did? All I
 can say is that, for my system, yum saw version conflicts that were
 blockers.
 
 As for properly, there are, as Larry Wall says, many ways to do it. It is
 up to each project, as their first task, IMHO, to see to it that
 ./configure, make, make install works for their package, with proper,
 documented flags, on standard Linux distros. Ganglia - a fine and valuable
 project on the whole - has a broken make install. But it can be worked
 around. Finding workarounds is often a sysadmins job. Sharing those
 workarounds with the community is often how free software stays ahead of the
 proprietary stuff. 
 
 On the whole, this list is professional. I like that. But look,
 ./configure, make, make install is _always_ a proper option. Any serious
 business will have need of building on occassional program with different
 flags than the distro's default, whatever the distro. I often end up
 building a few core applications that way, as do many other sysadmins in
 serious business settings. If you don't need to, that's fine. Some
 businesses can wear off-the-rack cloths. Others need tailored garments.
 
 Regards,
 Whit
 ___
 CentOS mailing list
 CentOS@centos.org
 http://lists.centos.org/mailman/listinfo/centos
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Ganglia

2010-06-18 Thread Whit Blauvelt
 On Thu, Jun 17, 2010 at 08:19:46PM -0500, John R. Dennison wrote:

   If there were a good CentOS build of 3.1.7 I'd happily use it. But getting
   stuff from EPEL, which is essentially Redhat testing, is as silly as 
   mixing
  
  Uh, you've confused EPEL and Fedora apparently.

Hey John,

https://fedoraproject.org/wiki/EPEL:

Extra Packages for Enterprise Linux (EPEL) is a volunteer-based community
effort from the Fedora project to create a repository of high-quality add-on
...

Enough said.

Whit
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Ganglia

2010-06-18 Thread Les Mikesell
On 6/18/2010 9:01 AM, Whit Blauvelt wrote:

 If there were a good CentOS build of 3.1.7 I'd happily use it. But getting
 stuff from EPEL, which is essentially Redhat testing, is as silly as mixing

 Uh, you've confused EPEL and Fedora apparently.

 Hey John,

 https://fedoraproject.org/wiki/EPEL:

 Extra Packages for Enterprise Linux (EPEL) is a volunteer-based community
 effort from the Fedora project to create a repository of high-quality add-on
 ...

 Enough said.

Apparently not, since you don't seem to understand the purpose of the 
project, the relationship to the sponsor organization, or the value of 
high-quality, well maintained packages.  Or even the value of having 
machines where for spans of many years, all you ever have to do is yum 
update and the right thing will happen to every installed application.

-- 
   Les Mikesell
lesmikes...@gmail.com
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Ganglia

2010-06-18 Thread Les Mikesell
On 6/18/2010 8:20 AM, Jerry McAllister wrote:
 On Fri, Jun 18, 2010 at 08:14:02AM -0400, Whit Blauvelt wrote:

 On Thu, Jun 17, 2010 at 08:22:35PM -0500, John R. Dennison wrote:

 Is this vitriol really necessary?  I installed ganglia; not a
 single conflict.

 Why yes, John, it is. The fine man said outright he didn't believe my honest
 account, accusing me of making something up when I was only giving the
 facts. He was calling me a liar. He preferred to see my account as a lie so
 as not to surrender his faith that Ganglia is a pure and perfect project.

 there is a big difference in saying you don't believe a person's
 information and calling them a liar.You may just be saying you
 perceive things differently or maybe that the person doesn't understand
 about which he is speaking.   He may be entirely truthful and still
 not be believed.

And there's a gray area where what the person says is technically true 
regarding his observations but then he places blame on others for a 
situation he created himself.  The part not to be believed is the 
incorrect conclusion, especially when you can easily disprove it 
yourself - so its not a lie, it is a mistake.

-- 
   Les Mikesell
lesmikes...@gmail.com
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Ganglia

2010-06-18 Thread John R. Dennison
On Fri, Jun 18, 2010 at 08:14:02AM -0400, Whit Blauvelt wrote:
 
 Why yes, John, it is. The fine man said outright he didn't believe my honest
 account, accusing me of making something up when I was only giving the
 facts. He was calling me a liar. He preferred to see my account as a lie so
 as not to surrender his faith that Ganglia is a pure and perfect project.
 Attitudes like that are dangerous in computing, since they lead to bugs not
 being fixed.

While KBS could have very well chosen his wording differently
he did not call you a liar.  That is the interpretation you
choose to apply to what he said.  If someone tells me that it's
going to rain, and I see nothing but blue skies on the horizon
and tell them I don't believe them I am not calling them a
liar; I am, however, telling them that they are wrong.  By
this account I find your use of ignorant rude and uncalled
for.

 You installed without a conflict, good. Perhaps you were installing on a
 32-bit system rather than a 64-bit? Perhaps your system didn't have some of
 the packages already installed for other functionality that mine did? All I
 can say is that, for my system, yum saw version conflicts that were
 blockers.

Yep, 32-bit.  As you didn't point out whether you attempted the
32-bit or 64-bit version I grabbed a test box at random and it 
happened to be 32-bit.  

As far as conflicts go I will say again, I didn't have any.  And
without further evidence from you there's no way to determine
why you are reporting alleged conflicts, nor what those
conflicts may be.  If there are conflicts it's it is much more
likely that they stem from self-installs or poorly chosen
3rd party repos then they do with EPEL.

 As for properly, there are, as Larry Wall says, many ways to do it. It is
 up to each project, as their first task, IMHO, to see to it that
 ./configure, make, make install works for their package, with proper,
 documented flags, on standard Linux distros. Ganglia - a fine and valuable
 project on the whole - has a broken make install. But it can be worked
 around. Finding workarounds is often a sysadmins job. Sharing those
 workarounds with the community is often how free software stays ahead of the
 proprietary stuff. 

This doesn't carry much weight with me when we are talking about
an enterprise distro unless the problems are discovered in the
process of building SRPMs.

By the way, did you report this issue upstream and offer them
the workarounds in the form of patches?

 On the whole, this list is professional. I like that. But look,
 ./configure, make, make install is _always_ a proper option. Any serious

No, it's not.

 business will have need of building on occassional program with different
 flags than the distro's default, whatever the distro. I often end up

And those needs are best met by rolling SRPMs.  Heck, you could
even give back to the community and make them available for
others to make use of.

 building a few core applications that way, as do many other sysadmins in
 serious business settings. If you don't need to, that's fine. Some
 businesses can wear off-the-rack cloths. Others need tailored garments.

I don't dispute this at all; it's very true and will remain
true.

My argument is that building native tarballs and then installing
them is *not* the way to go when you are working with a package
managed system such as CentOS; take the additional time and make
SRPMs that can be properly integrated into the package system.
The benefits from such can not be understated and are *well*
worth your time.  You're not new to the industry so I'm a little
confused as to why you don't see this.




John
-- 
A nuclear war does not defend a country and it does not defend a system.
I've put it the same way many times; not even the most accomplished
ideologue will be able to tell the difference between the ashes of
capitalism and the ashes of communism.

-- John Kenneth Galbraith (1908 - 2006), Canadian-American economist and
author, The Ashes of Capitalism and the Ashes of Communism, interview
with John M.  Whiteley in Quest for Peace: an Introduction (1986)


pgpU7FryXu2Br.pgp
Description: PGP signature
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Ganglia

2010-06-18 Thread John R. Dennison
On Fri, Jun 18, 2010 at 08:25:56AM -0400, Whit Blauvelt wrote:
 
 To get 3.1.7? Disregarding that, I should jump through the hoops of
 recompiling a F13 RPM rather than just compile from the tar? Why? Every
 extra stage like that introduces the chance of incidental errors, of stuff
 that doesn't translate precisely through that stage. I'm not doubting it
 generally can work, just that there's anything proper about it. Generally
 native source is the gold standard. The farther upstream you go, the better
 the quality gets, the more bugs are fixed, and the more control you have
 over how and where the stuff installs on your systems. 

You really believe this?  If so, why do you bother with CentOS,
or any package managed distro?  Native builds are *never* the
way to go, but I quite refuse to waste my time pointing out the
many drawbacks of such compared to taking a few moments to
properly - yes, *properly* - make SRPMs and and rebuilding
*those* on the target platforms.

The gold standard is that procedure, not building source kits
that can, and *will* walk all over the rest of your system.
Just because it may not have happened yet is nothing but pure
luck.

 There can be an argument that for some stuff that passes through RHEL the
 extra attention adds some quality control (ignoring the counterexample of
 the long history of RH manging kernels; they seem to have gotten better
 about that lately), but stuff in EPEL? Really?

Some quality control?  Really?  I can see this discussion is
going no where and you have your mind made up.  





John
-- 
He may be mad, but there's method in his madness.  There nearly always is
method in madness.  It's what drives men mad, being methodical.

-- G. K. Chesterton, The Fad of the Fisherman (1922)


pgpaaZ0FVce4m.pgp
Description: PGP signature
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Ganglia

2010-06-18 Thread John R. Dennison
On Fri, Jun 18, 2010 at 08:41:26AM -0400, Whit Blauvelt wrote:
 
 Now you're threatening to expel me from the community? For posting notes on
 workarounds to get a useful package to work? What's this about? Ganglia's
 working fine for me.

I'm honored that you think I have that much sway in this
community that I would be able to expel you from it.  The
reality, however, is quite different.  I don't speak for the
project, nor do I speak for the community as a whole; I have
enough difficulty speaking for myself.

My issues were your building from native source doing the
standard three-step; it's wrong to do so in an rpm-managed
distro.  

 My claims? The project's own documents describe this stuff. You saw no
 conflicts? Great. Not every bug shows up on every box. You believe one
 instance of not seeing a bug means no on else will? That's Microsoft-style
 quality control.

Yes, *claims*.  You've provided no evidence except your claims
that it didn't work.  And please understand that I said it
worked *for me* and that *I* didn't see a conflict.  I never
said it wasn't an issue for others.  Had I noticed a problem I'd
also have taken the time to document such to the parties
responsible, including this mailing list.

 Sorry. If that's confusion, I got it from instructions (several sets of
 them) out on the web for installing Ganglia from EPEL, which referred to it
 as a Fedora repository. 

Yep, confusion.  You do, I hope, realize that EL and the
offspring of EL including CentOS are based on Fedora?  This
makes Fedora the test base for future EL cuts.  EPEL is just a
3rd party repo providing (mostly) Fedora kit rebuilt for EL use
in CentOS, SL, etc.

 I said I've been a Linux sysadmin since '93. I've been in the industry since
 '82. Thanks for mistaking me for a youngster though!

That's nice.  With an illustrious background such as yours I'd
expect less argument over the merits of SRPMs vs native builds
and a better understanding of EPEL's role.



John

-- 
Most people hate the idea of evolution because they realize that if it were
working properly, they'd be dead.

-- Anonymous


pgpXlCUvcu0D8.pgp
Description: PGP signature
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Ganglia

2010-06-18 Thread John R Pierce
John R. Dennison wrote:

 On the whole, this list is professional. I like that. But look,
 ./configure, make, make install is _always_ a proper option. Any serious
 

   No, it's not.
   

indeed, doing exactly this could very well lead to the conflicts he 
reported when he tried to install ganglia from EPEL.


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Ganglia

2010-06-18 Thread John R. Dennison
On Fri, Jun 18, 2010 at 10:01:38AM -0400, Whit Blauvelt wrote:
 
 Extra Packages for Enterprise Linux (EPEL) is a volunteer-based community
 effort from the Fedora project to create a repository of high-quality add-on
 ...
 
 Enough said.

Apparently not as that bears no indication of it being a test
base as your initial claim stated.




John

-- 
We must respect the other fellow's religion, but only in the same sense and
to the extent that we respect his theory that his wife is beautiful and his
children smart.

-- H. L. Mencken (1880-1956), writer, editor, and critic


pgpWRiSBxPsru.pgp
Description: PGP signature
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Ganglia

2010-06-18 Thread m . roth
John R. Dennison wrote:
 On Fri, Jun 18, 2010 at 08:41:26AM -0400, Whit Blauvelt wrote:
snip
   My issues were your building from native source doing the
   standard three-step; it's wrong to do so in an rpm-managed
   distro.

Up until now, I had to build the gspca driver separately, every time I
upgraded those servers with the cameras attached. I also *always* have to
do something - mostly reinstall - when I upgrade the boxes, mostly older,
with nvidia drivers. (And let's not talk about the newest upgrade to FC
13, which has none)

Even such a large install as CentOS/RHEL can't cover all hardware.

  mark

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Ganglia

2010-06-18 Thread John R. Dennison
On Fri, Jun 18, 2010 at 03:15:41PM -0400, m.r...@5-cent.us wrote:

 Up until now, I had to build the gspca driver separately, every time I
 upgraded those servers with the cameras attached. I also *always* have to
 do something - mostly reinstall - when I upgrade the boxes, mostly older,
 with nvidia drivers. (And let's not talk about the newest upgrade to FC
 13, which has none)

And what is the problem with the dkms-gspca stuff at rpmforge?

 Even such a large install as CentOS/RHEL can't cover all hardware.

Nor should it have to.  There exist vetted 3rd-party repos
that provide support for much that EL does not.





John

-- 
The Earth is a very small stage in a vast cosmic arena.  Think of the
rivers of blood spilled by all those generals and emperors so that, in
glory and triumph, they could become the momentary masters of a fraction of
a dot.  Think of the endless cruelties visited by the inhabitants of one
corner of this pixel on the scarcely distinguishable inhabitants of some
other corner, how frequent their misunderstandings, how eager they are to
kill one another, how fervent their hatreds.

-- Carl Sagan (1934-1996), astronomer and writer


pgpphF5Xq1DvH.pgp
Description: PGP signature
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Ganglia

2010-06-18 Thread Karanbir Singh
On 19/06/2010 02:02, Karanbir Singh wrote:
 ganglia - I still think you don't think you what you are talking about.

s/.*/ganglia - I still think you are confused about the issue./

I blame too much mongodb in one day for crazy language skilz :! ( or in
my case, lack of )

- KB
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


[CentOS] Ganglia

2010-06-17 Thread Whit Blauvelt
On Tue, Jun 15, 2010 at 04:07:57PM +0100, Simon Billis wrote:

 Take a look at ganglia - http://ganglia.sourceforge.net/
 
 This may do what you need. 

It's what I've ended up going with. (Munin also looked promising - if I
could get the syntax right to modify its CPU test for individual cores,
which looks quite possible, I just didn't achieve it yet).

A few notes on Ganglia 3.1.7 build/install:

- best complied from source, there are big dependency problems with the
  available rpms 

- dependencies to satisfy before compilation include (among others):
  apr-devel libconfuse libconfuse-devel expat-devel pcre-devel - for the
  libconfuse I went to dag/rpmforge

- the make install stage doesn't fully install, despite a required
  --sysconfdir flag being used. In particular, gmond -t  gmond.conf will
  provide the missing file to add to your config dir for that. The
  ganglia-3.1.7/gmond/modules/conf.d contents should be copied to
  /etc/ganglia/conf.d. Then a line with include
  ('/etc/ganglia/conf.d/*.conf') should be added to gmond.conf. And the man
  pages (in mans and one for gmond.conf in gmond) may be copied
  /usr/share/man/man1 and man5 as appropriate. Also, the init files for
  gmond and gmetad need to be copied to init.d - but at least this, unlike
  the other hand-installation requirements, is documented.

- Beyond that, it's good to change the cluster name = in gmond.conf to
  something appropriate before you start to run. You only need gmetad
  compiled on the system to run the web reporting front end (and it takes an
  configure flag to do that). On other systems just rsycing over the
  /etc/ganglia contents will handle configuration just fine (assuming this
  is a single cluster). The web pages merely require copying to someplace in
  your PHP-capable server's space.

- The multi-core CPU graphing module - the main functionality I was after -
  requires some uncommenting in its conf file to get it going. The PCRE
  section is enough to uncomment, with pcre installed on your system.

It's pretty simple once the dependencies are installed, and the make
install deficiencies are worked around. It gives a _lot_ of graphs
(probably too many, but studying them over time will tell).

Whit
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Ganglia

2010-06-17 Thread Karanbir Singh
On 17/06/2010 23:20, Whit Blauvelt wrote:
 - best complied from source, there are big dependency problems with the
   available rpms 

I find that very hard to believe - to the extent that I don't believe
you at all. Or did you mean to say that its not easy to locate a well
done rpm set for ganglia ?

I've never used ganglia in anger, but know lots and lots of people who
do - its the most used trending tool in the hpc world.

Also, one thing you did'nt mention is that its exceptionally insecure
out of the box, by design. Its meant to be easy to get going and
offloads security to site and network policy since most implementations
run on isolated management networks no where near the internet. So if
you are using it in a situation where you care about who can connect to
our agents and what data is seen over the wires - start by spending a
few hours securing your install.

- KB
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Ganglia

2010-06-17 Thread John R. Dennison
On Thu, Jun 17, 2010 at 06:20:03PM -0400, Whit Blauvelt wrote:
 
 - best complied from source, there are big dependency problems with the
   available rpms 

Very few packages are ever best compiled from source on an
enterprise distro.

What, specifically, is wrong with the 3.0.7 in EPEL?




John

-- 
Mankind is a single body and each nation a part of that body.  We must
never say What does it matter to me if some part of the world is ailing?
If there is such an illness, we must concern ourselves with it as though we
were having that illness.

Mustafa Kemal Ataturk (1881-1938), founder and first President of the
Republic of Turkey


pgpVDozj5Jldj.pgp
Description: PGP signature
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Ganglia

2010-06-17 Thread Joshua Baker-LePain
On Thu, 17 Jun 2010 at 6:51pm, John R. Dennison wrote

 On Thu, Jun 17, 2010 at 06:20:03PM -0400, Whit Blauvelt wrote:

 - best complied from source, there are big dependency problems with the
   available rpms

   Very few packages are ever best compiled from source on an
   enterprise distro.

   What, specifically, is wrong with the 3.0.7 in EPEL?

Well, if you have more than 4TB of RAM in your grid, the memory graph 
wraps.  :)  Other than that, though, it works wonderfully.

That being said, it's trivial to recompile the F13 RPM for 3.1.2 for 
centos-5.

-- 
Joshua Baker-LePain
QB3 Shared Cluster Sysadmin
UCSF
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Ganglia

2010-06-17 Thread Whit Blauvelt
On Fri, Jun 18, 2010 at 12:37:11AM +0100, Karanbir Singh wrote:
 On 17/06/2010 23:20, Whit Blauvelt wrote:
  - best complied from source, there are big dependency problems with the
available rpms 
 
 I find that very hard to believe - to the extent that I don't believe
 you at all. Or did you mean to say that its not easy to locate a well
 done rpm set for ganglia ?

I should care what you believe? Stay ignorant, if you like. If not, take a
CentOS system, add the EPEL repository for ganglia, try yum install
ganglia, and prepare to see all sorts of package conflicts. Plus it's not
the current ganglia anyway. Better to build from tar.

 I've never used ganglia in anger, but know lots and lots of people who
 do - its the most used trending tool in the hpc world.

What the heck do you mean, used ganglia in anger? That's just incoherent.
I'm happy with it. It's working nicely now. But the make install scripting
is buggy, so I posted what I've learned about working around that.

 Also, one thing you did'nt mention is that its exceptionally insecure
 out of the box, by design. Its meant to be easy to get going and
 offloads security to site and network policy since most implementations
 run on isolated management networks no where near the internet. So if
 you are using it in a situation where you care about who can connect to
 our agents and what data is seen over the wires - start by spending a
 few hours securing your install.

I did't say my notes were a full article on it! My implementation is, as you
suggest, far from the internet. I'll be happy to discuss firewalling and
network segmentation if those questions come up. 

Regards,
Whit
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Ganglia

2010-06-17 Thread Whit Blauvelt
On Thu, Jun 17, 2010 at 06:51:52PM -0500, John R. Dennison wrote:

   Very few packages are ever best compiled from source on an
   enterprise distro.
 
   What, specifically, is wrong with the 3.0.7 in EPEL?

Um, that yum install ganglia produces a long list of package conflicts on
a current CentOS system? Or that only 3.1.7 has a fully working multicpu
module, plus a number of significant bug fixes?

If there were a good CentOS build of 3.1.7 I'd happily use it. But getting
stuff from EPEL, which is essentially Redhat testing, is as silly as mixing
stuff from Debian testing into Debian stable, as far as enterprise systems
go. On the other hand, I've run a number of enterprise systems on Gentoo.
I'm sure the compiling of everything from source there gives you absolute
horrors. But those systems treated me well for years. Now I'm in a mixed
Ubuntu/CentOS environment, and I stay with distro packages ... until I
don't. When there's a specific program that I need compiled with different
options or whatever, well, I've been a Linux sysadmin since '93. I kind of
know what I'm doing.

What's with you kids these days? Compiling something from tar isn't going to
blow things up. At least it's never bitten me, in 17 years. 

Best,
Whit
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Ganglia

2010-06-17 Thread John R. Dennison
On Thu, Jun 17, 2010 at 08:01:02PM -0400, Joshua Baker-LePain wrote:
 
 That being said, it's trivial to recompile the F13 RPM for 3.1.2 for 
 centos-5.

And that would be the proper route to go instead of building
from native source :)




John

-- 
Which is more believable: In the beginning there was God, who created the
universe, or in the beginning there was nothing, which exploded

-- nog


pgpcT7MjIYvf6.pgp
Description: PGP signature
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Ganglia

2010-06-17 Thread John R. Dennison
On Thu, Jun 17, 2010 at 08:21:00PM -0400, Whit Blauvelt wrote:
 
 Um, that yum install ganglia produces a long list of package conflicts on
 a current CentOS system? Or that only 3.1.7 has a fully working multicpu
 module, plus a number of significant bug fixes?

I just tried a ganglia install from EPEL; absolutely no issues
at all.  Perhaps if you'd bother to actually document these
conflicts one of us might be able to help.  That is if we're
still willing.

I can't speak to your claims of 3.1.7 having bug fixes and
the multicpu issue; but I saw no conflicts with EPEL's 3.0.7.


 If there were a good CentOS build of 3.1.7 I'd happily use it. But getting
 stuff from EPEL, which is essentially Redhat testing, is as silly as mixing

Uh, you've confused EPEL and Fedora apparently.

 stuff from Debian testing into Debian stable, as far as enterprise systems
 go. On the other hand, I've run a number of enterprise systems on Gentoo.
 I'm sure the compiling of everything from source there gives you absolute

Gentoo is fine for a toy os.  Claiming Gentoo is enterprise is
just silly.

 horrors. But those systems treated me well for years. Now I'm in a mixed
 Ubuntu/CentOS environment, and I stay with distro packages ... until I
 don't. When there's a specific program that I need compiled with different
 options or whatever, well, I've been a Linux sysadmin since '93. I kind of
 know what I'm doing.

If you say so.

 What's with you kids these days? Compiling something from tar isn't going to
 blow things up. At least it's never bitten me, in 17 years. 

Kids?  Heh.  17 years?  Heh.  You're a youngster.  Let me know
when you've got 25+ years in the industry and then I might be
impressed :)




John

-- 
Anybody can win unless there happens to be a second entry.

-- George Ade (1866 - 1944), American writer, newspaper columnist,
and playwright


pgpyWyqUIUexE.pgp
Description: PGP signature
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Ganglia

2010-06-17 Thread John R. Dennison
On Thu, Jun 17, 2010 at 08:09:11PM -0400, Whit Blauvelt wrote:
 
 I should care what you believe? Stay ignorant, if you like. If not, take a
 CentOS system, add the EPEL repository for ganglia, try yum install
 ganglia, and prepare to see all sorts of package conflicts. Plus it's not
 the current ganglia anyway. Better to build from tar.

Is this vitriol really necessary?  I installed ganglia; not a 
single conflict.

If you want shiny and new, why not do it properly and build
rpms?




John

-- 
He who knows that enough is enough will always have enough.

-- Lao-Tzu (BC 600-?), Chinese philosopher, founder of Taoism


pgpBVdE4avVIu.pgp
Description: PGP signature
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos