Re: [Ganglia-developers] Ganglia 3.1.x release plan
On Friday 11 July 2008 07:02:04 am Carlo Marcelo Arenas Belon wrote: On Thu, Jul 10, 2008 at 11:37:23AM -0700, Bernard Li wrote: Here's the release plan for the upcoming 3.1 release. do you mean 3.1.0? I believe all the important, show-stopping backport proposals in the STATUS file for 3.1 branch have already been processed and voted on. actually there is 1 showstopper reported there which has not yet a resolution, and that is the probable licensing issue between the BSD ganglia-webfrontend and the GPL templatePower class. sadly, I hadn't heard back from Ron (the author of templatePower) on the alternatives we might be able to go with and so can't comment in that. but checking again all legalese that seems to be tied into the files in the web frontend, it might seem we could be OK after all as the terms of the BSD license there (which actually look more like a MIT license to me) seem compatible with the terms of GPLv2. but of course IANAL and we should probably seek advice from one (maybe debian legal or fedora legal could help there). Tom Callaway is Fedora's first line of defense when it comes to licensing questions, and either he knows the answer from looking into tons of package licensing issues already, or knows who to talk to. -- Jarod Wilson [EMAIL PROTECTED] - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] [RFT]: build: linux 64bit biarch support
On Tuesday 08 July 2008 07:14:25 am Carlo Marcelo Arenas Belon wrote:
On Mon, Jul 07, 2008 at 09:10:37AM -0400, Jarod Wilson wrote:
On Monday 07 July 2008 04:46:05 am Carlo Marcelo Arenas Belon wrote:
On Wed, Jul 02, 2008 at 09:27:02AM -0400, Jarod Wilson wrote:
On Wednesday 02 July 2008 07:36:41 am Carlo Marcelo Arenas Belon
wrote:
The following proposed patch for stable 3.1, replaces the configure
routine that tried to guess the libdir directory by assuming biarch
rules from fedora linux (breaking all amd64 BSD and x64 Solaris)
and overriding the libdir parameter passed at configure time
(breaking fedora linux ppc64).
Contains changes from r1452, r1467, r1468, r1475 and r1487
At a glance, yeah, this looks like it should indeed finally Do The
Right Thing(tm) on all Linux architectures for both 32-bit and
64-bit.
It didn't, I found it was broken in an ia64 SuSE Enterprise Server 10
server.
D'oh. How so?
It would use an unexpanded libdir variable to replace all the libdir
entries in the configuration and code (the embedded gmond configuration),
so if no configuration was available and --libdir wasn't used it will end
up trying to load all modules from a directory named literally :
${exec_prefix}/lib
Oh, ew, ouch.
A fix has been committed to trunk already, but it is so interlinked
with another patch to remove the need to hardcode libdir in the
configurations from Brad that it might as well require it (or both
patches together) backported as a solution.
Never mind, I can just take a look at trunk and spin up one of my own
ia64 boxes...
It should had been broken in alpha as well (if you still have one of those
and the host I guessed is right)
No alphas here. Well, there are some collecting dust somewhere in the lab, I
believe... But no Fedora or Red Hat Enterprise Linux on Alpha for a while
now, so they don't get much love... My ia64 Fedora build (with --libdir
explicitly passed in) looks perfectly sane, haven't got around to poking at
things beyond a simple rpmbuild of the rawhide packages though.
please use the alternative proposed patch instead, which is IMHO the only
safe way to ensure this patch doesn't break something else.
Okay, sounds good.
--
Jarod Wilson
[EMAIL PROTECTED]
-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
Ganglia-developers mailing list
Ganglia-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] [RFT]: build: linux 64bit biarch support
On Monday 07 July 2008 04:46:05 am Carlo Marcelo Arenas Belon wrote: On Wed, Jul 02, 2008 at 09:27:02AM -0400, Jarod Wilson wrote: On Wednesday 02 July 2008 07:36:41 am Carlo Marcelo Arenas Belon wrote: The following proposed patch for stable 3.1, replaces the configure routine that tried to guess the libdir directory by assuming biarch rules from fedora linux (breaking all amd64 BSD and x64 Solaris) and overriding the libdir parameter passed at configure time (breaking fedora linux ppc64). Contains changes from r1452, r1467, r1468, r1475 and r1487 At a glance, yeah, this looks like it should indeed finally Do The Right Thing(tm) on all Linux architectures for both 32-bit and 64-bit. It didn't, I found it was broken in an ia64 SuSE Enterprise Server 10 server. D'oh. How so? A fix has been committed to trunk already, but it is so interlinked with another patch to remove the need to hardcode libdir in the configurations from Brad that it might as well require it (or both patches together) backported as a solution. Never mind, I can just take a look at trunk and spin up one of my own ia64 boxes... -- Jarod Wilson [EMAIL PROTECTED] - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] [RFT]: build: linux 64bit biarch support
On Wednesday 02 July 2008 07:36:41 am Carlo Marcelo Arenas Belon wrote: The following proposed patch for stable 3.1, replaces the configure routine that tried to guess the libdir directory by assuming biarch rules from fedora linux (breaking all amd64 BSD and x64 Solaris) and overriding the libdir parameter passed at configure time (breaking fedora linux ppc64). Contains changes from r1452, r1467, r1468, r1475 and r1487 At a glance, yeah, this looks like it should indeed finally Do The Right Thing(tm) on all Linux architectures for both 32-bit and 64-bit. -- Jarod Wilson [EMAIL PROTECTED] - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] [RFT]: build: linux 64bit biarch support
On Wednesday 02 July 2008 09:37:55 am Marcus Rueckert wrote: On 2008-07-02 06:36:41 -0500, Carlo Marcelo Arenas Belon wrote: The following proposed patch for stable 3.1, replaces the configure routine that tried to guess the libdir directory by assuming biarch rules from fedora linux (breaking all amd64 BSD and x64 Solaris) and overriding the libdir parameter passed at configure time (breaking fedora linux ppc64). Contains changes from r1452, r1467, r1468, r1475 and r1487 [...] i would never ever default libdir to $prefix/lib64. there are linux distros which default to single arch on x86_64. imho the default should always be plain $prefix/lib and if the packager/user is on a biarch system he has to specify --libdir. It seems most single-arch x86_64 distros have a compatibility symlink from lib to lib64, so it should work fine there too. Granted, yes, this could screw up a few people using single-arch x86_64 distros w/o a lib64 dir, but the failure mode should be obvious, and this probably helps more people than it hurts, since plenty of people building from source on bi-arch x86_64 neglect to pass in --libdir=/usr/lib64 and can wind up with less-than-obvious failure modes. I don't particularly care one way or the other myself, so long as I can pass in the correct libdir via configure, which is always done for rpm builds, of course. -- Jarod Wilson [EMAIL PROTECTED] - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] It's time to release 3.1...
On Friday 27 June 2008 08:05:22 am Carlo Marcelo Arenas Belon wrote:
On Wed, Jun 25, 2008 at 09:24:13AM -0400, Jarod Wilson wrote:
As you can see, we also build ppc32 userspace by default, ppc64 only when
explicitly requested.
so you are using CFLAGS=-m64 to force a ppc64 built then?.
Yep, its part of the CFLAGS passed in by the %configure macro when
doing 'rpmbuild --target ppc64 ...'.
version 1468 of
configure.in in trunk uses a new test which should be effect on guessing
which libdir and should work even if --libdir wasn't used as it uses the
compile time ABI instead of the installed CPU type.
I'll try to get around to poking at it soonish, but I'm a bit buried with
other stuff right now.
PS. if you have access to s390x would be nice to run a build there to see
if we got lucky with that platform as well,
I'd have to jump through some hoops to get running on s390x, don't have
anything standing by, immediately ready. There's always the hercules s390{,x}
emulator... :) (which actually works pretty well for basic s390/x testing,
albeit very slowly).
and who knows maybe also with
ia64 and mips64 eventhough I don't think there is biarch support from any
distribution for those too.
I've got ia64 immediately available, no mips64 though. ia64 is 64-bit only,
except for the 32-bit x86 emulation stuff that it can do, but that's a mutant
beast that you need not worry about... So yeah, ia64 simply uses /usr/lib, no
lib64 usage.
--
Jarod Wilson
[EMAIL PROTECTED]
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Ganglia-developers mailing list
Ganglia-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] It's time to release 3.1...
On Wednesday 25 June 2008 07:25:43 am Carlo Marcelo Arenas Belon wrote:
which is why I presume fedora ppc and therefore the fedora ppc package
will be 32bit and should be using /usr/lib, right?, therefore the only
builds that should be supported in fedora will be: i386, x86_64 and
ppc.
Nope, we'll have i386, x86_64, ppc and ppc64 builds. But unless you
specifically request to install the ppc64 version on a ppc64 kernel,
you'll get the ppc (32-bit) build installed. We still build everything
ppc64 as well as ppc (when it builds), it just doesn't get installed by
default.
can you then run the following in a fedora ppc (64bit enabled) system?
$ echo int main() { return 0; } t.c
$ gcc -c -o t.o t.c
$ file t.o
$ gcc -m32 -c -o t.o t.c
$ file t.o
$ gcc -m64 -c -o t.o t.c
$ file t.o
$ rm -f t.c t.o
[EMAIL PROTECTED] ~]$ uname -a
Linux xero.usersys.redhat.com 2.6.25.6-55.fc9.ppc64 #1 SMP Tue Jun 10 15:58:12
EDT 2008 ppc64 ppc64 ppc64 GNU/Linux
[EMAIL PROTECTED] ~]$ echo int main() { return 0; } t.c
[EMAIL PROTECTED] ~]$ gcc -c -o t.o t.c
[EMAIL PROTECTED] ~]$ file t.o
t.o: ELF 32-bit MSB relocatable, PowerPC or cisco 4500, version 1 (SYSV), not
stripped
[EMAIL PROTECTED] ~]$ gcc -m32 -c -o t.o t.c
[EMAIL PROTECTED] ~]$ file t.o
t.o: ELF 32-bit MSB relocatable, PowerPC or cisco 4500, version 1 (SYSV), not
stripped
[EMAIL PROTECTED] ~]$ gcc -m64 -c -o t.o t.c
[EMAIL PROTECTED] ~]$ file t.o
t.o: ELF 64-bit MSB relocatable, 64-bit PowerPC or cisco 7500, version 1
(SYSV), not stripped
As you can see, we also build ppc32 userspace by default, ppc64 only when
explicitly requested.
and then I presume the hack had just backfired and broke the ppc
package?
Most likely. Not sure I actually tried a ppc build until taking in the
patch that just uses whatever libdir was passed in from the %configure
macro.
if all your %configure invocations use --libdir then we should be clean for
all the builds already.
Yep, --libdir is always passed in by %configure, and things all built fine for
all arches in our build system right now. Initially, powerpc64 builds failed,
then I think one intermediate patch variant might have broken powerpc32
builds (this is the part I didn't actually try on ppc32), and now
everything's all good. :)
--
Jarod Wilson
[EMAIL PROTECTED]
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Ganglia-developers mailing list
Ganglia-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] It's time to release 3.1...
On Tuesday 24 June 2008 06:45:14 am Carlo Marcelo Arenas Belon wrote: attached an implementation which fixes the 2 issues raised before and also does some extra cleanup, but that will need more testing in different Linux distributions and with different autoconf versions before it can be backported. as explained before, I don't think is a good solution though as it is just extending the original hack (which wasn't really needed either) Just had another thought with respect to setting lib64 if host_cpu=powerpc64... The vast majority of the time, a 32-bit userspace is actually preferred on 64-bit PowerPC -- 32-bit ppc doesn't have the register limitations 32-bit x86 has. The gains you see with 64-bit x86_64 over 32-bit x86, outside of addressable memory, don't exist when going to 64-bit ppc binaries (since ppc32 has a saner register space than x86), and you often get marginally slower code, since there's an expanded memory footprint. Need for huge amounts of memory is one of the few reasons to run a 64-bit ppc binary on a 64-bit ppc kernel. In other words, yes, lib64 is correct if building a ppc64 binary, but not for a ppc32 binary, which is actually what most people should be using on a ppc64 system. That being the case, if we automatically swap in lib64 on ppc64, it should probably be done only if host_cpu=powerpc64 *and* the binary being built is 64-bit. Hopefully, I'm making sense here... -- Jarod Wilson [EMAIL PROTECTED] - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] It's time to release 3.1...
Bernard Li wrote: Hi Jarod: On Wed, Jun 18, 2008 at 9:32 AM, Jarod Wilson [EMAIL PROTECTED] wrote: Almost. If you do a simple './configure', you wind up with libdir=/usr/lib on x86_64 and ppc64. That's actually fairly common though, and most distros that use lib64 know to pass in --libdir= on the configure line. If you want though, you could certainly further enhance the configure script to set lib64 on x86_64 and ppc64 if the user didn't pass in any libdir value. I believe that if you are building RPMs, if you use %configure in the spec file, the arch-dependent libdir of the system will be passed as --libdir, so I think in that sense we are fine. Yep, --libdir= is one of the standard flags passed in when using the %configure macro. I was thinking more of the case of people building their own bits from source. I have spent quite a bit of time on this and couldn't figure out any clean way to do the automatic configuration that you mentioned, so I will leave it at that for now. I will check this into trunk and submit a backport proposal for the 3.1 branch. Thanks all for participating in this discussion. No problem, sounds good enough to me. I'm no Makefile/configure guru myself, so no clue how it might be done either. :) -- Jarod Wilson [EMAIL PROTECTED] - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] It's time to release 3.1...
On Wednesday 18 June 2008 04:27:46 pm Bernard Li wrote: Hi Brad: On Wed, Jun 18, 2008 at 8:50 AM, Brad Nicholes [EMAIL PROTECTED] wrote: I tried this on SuSE x86_64 and it all seemed to work as expected. After you run ./configure (no flags), can you please check 'gmond/modules/conf.d/multicpu.conf' in your build directory to see if it is using the correct libdir (i.e. /usr/lib64) for 'path'? On my end, ./configure w/o flags on an x86_64 box resulted in a Makefile with 'libdir=/usr/lib' and multicpu.conf with 'path = /usr/lib/ganglia/modmulticpu.so'. -- Jarod Wilson [EMAIL PROTECTED] - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] It's time to release 3.1...
On Tuesday 17 June 2008 03:01:07 pm Brad Nicholes wrote: On 6/17/2008 at 12:39 PM, in message [EMAIL PROTECTED], Bernard Li [EMAIL PROTECTED] wrote: Hi Brad: Oh, and we need to address the build issue on powerpc64 -- Jarod any comments regarding how to best fix this? I guess hardcoding this in configure.in seems to solve the problem, but it doesn't sound like it's the best solution. I don't have a problem in getting issues like this resolved as long as they don't delay the release. These are the kinds of issues that if not fixed in this release, can easily be fixed in 3.1.2 or .3 or whatever releases. I don't really care if we release 3.1.1 in two weeks and then follow it with 3.1.2 a month later. I just think it is important that we get 3.1 officially released. I'd agree that this one isn't a huge deal. Things end up where they're supposed to, its just not done quite correctly yet. Haven't dug into what needs fixing, but basically, if a libdir value is passed in, it shouldn't be overridden. Its the correct default, just need to respect values people pass in via configure. -- Jarod Wilson [EMAIL PROTECTED] - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] It's time to release 3.1...
On Tuesday 17 June 2008 03:22:52 pm Jarod Wilson wrote: On Tuesday 17 June 2008 03:01:07 pm Brad Nicholes wrote: On 6/17/2008 at 12:39 PM, in message [EMAIL PROTECTED], Bernard Li [EMAIL PROTECTED] wrote: Hi Brad: Oh, and we need to address the build issue on powerpc64 -- Jarod any comments regarding how to best fix this? I guess hardcoding this in configure.in seems to solve the problem, but it doesn't sound like it's the best solution. I don't have a problem in getting issues like this resolved as long as they don't delay the release. These are the kinds of issues that if not fixed in this release, can easily be fixed in 3.1.2 or .3 or whatever releases. I don't really care if we release 3.1.1 in two weeks and then follow it with 3.1.2 a month later. I just think it is important that we get 3.1 officially released. I'd agree that this one isn't a huge deal. Things end up where they're supposed to, its just not done quite correctly yet. Haven't dug into what needs fixing, but basically, if a libdir value is passed in, it shouldn't be overridden. Its the correct default, just need to respect values people pass in via configure. Also, for the record, Fedora's ganglia maintenance is in the process of being handed off to Kostas Georgiou, who I'm adding to the cc here to keep him apprised of the situation. -- Jarod Wilson [EMAIL PROTECTED] - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] Ganglia 3.1.x r1399 snapshot released
On Friday 13 June 2008 04:54:48 am Carlo Marcelo Arenas Belon wrote: On Wed, Jun 11, 2008 at 01:15:07PM -0700, Bernard Li wrote: Hi Jarod: On Wed, Jun 11, 2008 at 12:55 PM, Jarod Wilson [EMAIL PROTECTED] wrote: ...and it fell apart on the ppc64 build. Well, not on the build, per se, but on the packaging. Part of the configure line passes in libdir=/usr/lib64, but everything that should have been under there went into /usr/lib instead. http://koji.fedoraproject.org/koji/getfile?taskID=658022name=build.log This (untested) patch should fix the issue without specifying --libdir: Index: configure.in === --- configure.in(revision 1399) +++ configure.in(working copy) @@ -574,7 +574,7 @@ prefix=$ac_default_prefix fi -if test x$host_cpu = xx86_64; then +if test x$host_cpu = xx86_64 || test x$host_cpu = xppc64; then libdir=$prefix/lib64 else libdir=$prefix/lib why is hardcoding the library path needed to begin with?, this is not portable (even in between linux distributions). Delayed reply, had to leave early Wednesday, was out of the office yesterday... Yeah, I had the same question. I expect this will get my ppc64 build working, but this really shouldn't be hard-coded when I'm explicitly passing in --libdir=/usr/lib64 (which configure --help says is valid). -- Jarod Wilson [EMAIL PROTECTED] - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] Ganglia 3.1.x r1399 snapshot released
On Wednesday 11 June 2008 04:15:07 pm Bernard Li wrote: Hi Jarod: On Wed, Jun 11, 2008 at 12:55 PM, Jarod Wilson [EMAIL PROTECTED] wrote: ...and it fell apart on the ppc64 build. Well, not on the build, per se, but on the packaging. Part of the configure line passes in libdir=/usr/lib64, but everything that should have been under there went into /usr/lib instead. http://koji.fedoraproject.org/koji/getfile?taskID=658022name=build.log This (untested) patch should fix the issue without specifying --libdir: Index: configure.in === --- configure.in(revision 1399) +++ configure.in(working copy) @@ -574,7 +574,7 @@ prefix=$ac_default_prefix fi -if test x$host_cpu = xx86_64; then +if test x$host_cpu = xx86_64 || test x$host_cpu = xppc64; then libdir=$prefix/lib64 else libdir=$prefix/lib Please let me know how it goes. Hrm, odd. Prior objections to the perceived hardcoding aside, the build fails identically with this patch applied. Digging some more now... -- Jarod Wilson [EMAIL PROTECTED] - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] Ganglia 3.1.x r1399 snapshot released
On Tuesday 10 June 2008 02:01:48 pm Bernard Li wrote: Hi all: The latest 3.1.x snapshot release is now available: http://www.ganglia.info/snapshots/3.1.x Changes from the last snapshot: - web: report correctly uptime in shownode when host is down - build: better support for solaris =8 and 10 - build: aix and darwin static build fixes - gmond: use fabs[f] values for floating metrics absolute calculation - gmond/web: SOURCE for metrics eliminated since core metrics are the same as user-defined metrics - devel: move all gexec specific structs from lib/ganglia_priv.h to include/ganglia_gexec.h We are nearing release of 3.1, please help us reach this goal sooner by testing on your systems and reporting any issues you may encounter. We are most interested in resolving all build related issues on different systems/architectures. To aid in the fun, I've committed r1399 to Fedora's development tree, and have a build going right now, across i386, x86_64, ppc and ppc64... -- Jarod Wilson [EMAIL PROTECTED] - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] Ganglia 3.1.x r1399 snapshot released
On Wednesday 11 June 2008 03:47:40 pm Jarod Wilson wrote: On Tuesday 10 June 2008 02:01:48 pm Bernard Li wrote: Hi all: The latest 3.1.x snapshot release is now available: http://www.ganglia.info/snapshots/3.1.x Changes from the last snapshot: - web: report correctly uptime in shownode when host is down - build: better support for solaris =8 and 10 - build: aix and darwin static build fixes - gmond: use fabs[f] values for floating metrics absolute calculation - gmond/web: SOURCE for metrics eliminated since core metrics are the same as user-defined metrics - devel: move all gexec specific structs from lib/ganglia_priv.h to include/ganglia_gexec.h We are nearing release of 3.1, please help us reach this goal sooner by testing on your systems and reporting any issues you may encounter. We are most interested in resolving all build related issues on different systems/architectures. To aid in the fun, I've committed r1399 to Fedora's development tree, and have a build going right now, across i386, x86_64, ppc and ppc64... ...and it fell apart on the ppc64 build. Well, not on the build, per se, but on the packaging. Part of the configure line passes in libdir=/usr/lib64, but everything that should have been under there went into /usr/lib instead. http://koji.fedoraproject.org/koji/getfile?taskID=658022name=build.log -- Jarod Wilson [EMAIL PROTECTED] - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] Testing RRDtool 1.3rc7 with Ganglia on CentOS 4.x
On Friday 06 June 2008 08:17:06 pm Bernard Li wrote: Hi guys: I was able to build RRDtool 1.3rc7 on CentOS 4.x and use it with Ganglia 3.0.7. I noticed there weren't much difference in system resource utilization: iostat shows ~2MB/s write, top shows load is roughly 4 (this is roughly the same as system running rrdtool 1.2.23). The main difference I notice is that the frontend's graphs actually looked fine. With version 1.2.23, I have a lot of gaps in the Load summary graphs (the red, green, blue lines which represents CPUs, Nodes and Running Processes respectively), with 1.3, the graphs don't have gaps (or at least very rarely have gaps). I noticed that the time it takes to generate the graphs is slightly faster. If you are interested in testing this for yourself, I have put the necessary RPMs online here: http://therealms.org/oss/ganglia/rrdtool/ Nb: Fedora 8, Fedora 9 and rawhide (Fedora development tree) all have rrdtool 1.3rc7 builds available as well in their respective yum repos (either in updates or updates-testing for F8 and F9, can't recall atm). -- Jarod Wilson [EMAIL PROTECTED] - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] Ganglia 3.0.7 (Fossett) Released
On Wednesday 27 February 2008 07:41:20 pm Bernard Li wrote: Dear all: Ganglia 3.0.7 has been released. This is a bugfix release with the following summary: - [web] Host view metric graphs' now (x.xx) number is always 0.00 - [web] Show Hosts toggled did not work - [gmond] Fix memory leak from network metrics on Linux (thanks Kumar Vaibhav for reporting) - [gmond] Fix spoof memory leak (thanks Martin Hicks for the patch) The Ganglia developers will be meeting tomorrow and Friday at GroundWork Open Source's main office in San Francisco to discuss plans for the next major 3.1.0 release. If you are interested in participating, please join us at #ganglia on irc.freenode.net. New Fedora builds working through the build system right now, will push 'em as updates when they're done... -- Jarod Wilson [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] Ganglia issue with RRDTool 1.3 beta3
On Tuesday 05 February 2008 10:04:00 am Jesse Becker wrote: On Feb 5, 2008 9:57 AM, Jarod Wilson [EMAIL PROTECTED] wrote: http://koji.fedoraproject.org/packages/rrdtool/1.3/0.6.beta3.fc9/ (despite the fc9 tag, it'll run just fine on Fedora 8 too) How about RHEL4 or 5? Less certain... For RHEL4 and RHEL5, I'd suggest perhaps doing a rebuild of the package, but the rrdtool already available for 'em in EPEL shouldn't have this memory leak problem. -- Jarod Wilson [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] Ganglia issue with RRDTool 1.3 beta3
On Tuesday 05 February 2008 10:11:15 am Jesse Becker wrote:
On Feb 5, 2008 10:08 AM, Jarod Wilson [EMAIL PROTECTED] wrote:
On Tuesday 05 February 2008 10:04:00 am Jesse Becker wrote:
On Feb 5, 2008 9:57 AM, Jarod Wilson [EMAIL PROTECTED] wrote:
http://koji.fedoraproject.org/packages/rrdtool/1.3/0.6.beta3.fc9/
(despite the fc9 tag, it'll run just fine on Fedora 8 too)
How about RHEL4 or 5?
Less certain... For RHEL4 and RHEL5, I'd suggest perhaps doing a rebuild
of the package, but the rrdtool already available for 'em in EPEL
shouldn't have this memory leak problem.
Rebuilding is fine. Those are just the types of systems that I have
availble for testing.
Sorry, yeah, I figured that, meant the latter part as a warning to users that
the current RHEL{4,5} packages should be unaffected by this problem.
For testing on an existing system where you may already have some data created
by pre-1.3 rrdtool, take note that you may need to do a dump and restore to
upgrade existing rrd's so they'll behave properly:
https://bugzilla.redhat.com/show_bug.cgi?id=397891
--
Jarod Wilson
[EMAIL PROTECTED]
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Ganglia-developers mailing list
Ganglia-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] Ganglia issue with RRDTool 1.3 beta3
On Tuesday 05 February 2008 02:36:35 am Carlo Marcelo Arenas Belon wrote: On Mon, Feb 04, 2008 at 01:02:03PM -0800, Bernard Li wrote: BTW, anything that can be done on the Fedora 8 side? Would it be possible to downgrade rrdtool...? the web frontend used to look for rrdtool in the gmetad root tree by default as shown in the comment in web/conf.php for the RRDTOOL define and was only using the rrdtool from the system if configured by enabling that define (couldn't find when the change was done in the recent SVN). in any case, a warning about using the rrdtool binary provided with F8 and commenting about the possibility of using another user provided version of it with the frontend through that setting could be added to a FAQ without having to resort to force a fix out into an externally provided package. I've already taken in patches for rrdtool in Fedora that Tobi thought might resolve the issue. If affected users could test 'em out to verify the fix, I'll get a build pushed into the proper updates repo ASAP. Test build: http://koji.fedoraproject.org/packages/rrdtool/1.3/0.6.beta3.fc9/ (despite the fc9 tag, it'll run just fine on Fedora 8 too) -- Jarod Wilson [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] Ganglia issue with RRDTool 1.3 beta3
On Monday 04 February 2008 01:56:46 pm Bernard Li wrote: Guys: I'd like to point you to this somewhat major issue: http://bugzilla.ganglia.info/cgi-bin/bugzilla/show_bug.cgi?id=170 RRDTool 1.3b3 is shipped with Fedora 8, so some users will be experiencing this issue. We should probably try to figure out whether this issue is with Ganglia or RRDTool and report to the appropriate people. Jarod, any comments regarding this? I'd probably blame rrdtool. I got another memory leak bug report against it just recently that didn't involve ganglia. https://bugzilla.redhat.com/show_bug.cgi?id=430879 Looking into it and engaging upstream rrdtool is on my todo list, but keeps getting filtered to the bottom of the pile... -- Jarod Wilson [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] Ganglia issue with RRDTool 1.3 beta3
On Monday 04 February 2008 05:08:24 pm Bernard Li wrote: Hi Jarod: On 2/4/08, Jarod Wilson [EMAIL PROTECTED] wrote: Unfortunately, I upgraded rawhide to track 1.3 long before the f8 release, thinking 1.3 would stabilize and be out before f8, then didn't really pay attention again until it was too late to roll back to 1.2.x before release. : \ Well hopefully a patch or a new beta will be out soon so that at least you could push out an updated version without the memory leak. If such is to occur I'll ping you regarding it. Sounds good. A bug fix (either by patch or new beta) would definitely be more optimal than rolling back, and I can get it pushed out the door pretty quickly. -- Jarod Wilson [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] Ganglia issue with RRDTool 1.3 beta3
On Monday 04 February 2008 04:02:03 pm Bernard Li wrote: Hi Jarod: On 2/4/08, Jarod Wilson [EMAIL PROTECTED] wrote: I'd probably blame rrdtool. I got another memory leak bug report against it just recently that didn't involve ganglia. https://bugzilla.redhat.com/show_bug.cgi?id=430879 Looking into it and engaging upstream rrdtool is on my todo list, but keeps getting filtered to the bottom of the pile... Thanks for the heads up -- I have updated a related bug report in RRDtool's bug tracker: http://oss.oetiker.ch/rrdtool-trac/ticket/115 BTW, anything that can be done on the Fedora 8 side? Would it be possible to downgrade rrdtool...? Not in a way that doesn't introduce other problems. It could be done by releasing a 1.2.x build with an epoch bump, but I think there may be some rrdtool db format issues between 1.2.x and 1.3 -- at least, there were multiple bug reports earlier on of people who upgraded to 1.3 and ran into problems with their graphs until doing rrd dump and restore routines to upgrade to the newer format db and get sane behavior again. I don't know for sure, but I presume a similar procedure might be required to go from 1.3 back down to 1.2. Unfortunately, I upgraded rawhide to track 1.3 long before the f8 release, thinking 1.3 would stabilize and be out before f8, then didn't really pay attention again until it was too late to roll back to 1.2.x before release. : \ -- Jarod Wilson [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] Ganglia versioning
Bernard Li wrote: My personal preference is to have the version part of the rpm name accurately reflect the package I am installing. If I see a package named ganglia-3.0.9-release, my expectation is that I am installing some form of ganglia-3.0.9. In this case, ganglia-3.0.9 doesn't really exist (in the sense that there is no official tagged ganglia-3.0.9 version). I found this page from the Fedora project about RPM naming that might be useful: http://fedoraproject.org/wiki/Packaging/NamingGuidelines I'm not saying that Ganglia needs to follow this convention, but it does have some good ideas about how to handle rpm names for betas, pre- releases, snapshots, etc. Basically, it relies on the release field to convey this information while still maintaining a strictly increasing version-release number. Maybe one of those ideas could be used/adapted to address the problem mentioned above. With our current naming convention, simply modifying the release field won't fly. Current convention: Release: 3.1.0-1 Snapshot: 3.1.0.200710101608-1 In Fedora rpm-speak, that would actually be Version: 3.1.0, Release: 1 Version: 3.1.0.200710101608, Release: 1 Since 3.1.0.200710101608 3.1.0, you will never be able to upgrade the snapshot RPM to the release RPM irregardless of what the release is. You could potentially get around this by using the epoch, but I personally do not like that. Yes, epoch's are fugly. Don't use 'em. The way to apply the Fedora conventions would be more like this: For a 3.1.0 pre-release snapshot: Version: 3.1.0, Release: 0.1.200710101608 For a 3.1.0 rc: Version: 3.1.0, Release: 0.2.rc1 For the 3.1.0 release: Version: 3.1.0, Release: 1 3.1.0-1 3.1.0-0.2.rc1 3.1.0-0.1.200710101608 (I've long been meaning to contribute back some of the changes I made for the ganglia spec used in Fedora, but have been sidetracked by a half-billion other things...) -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] Gagnlia 3.0.4 released
On Monday 25 December 2006 05:32, Martin Knoblauch wrote: Ho ho ho, Santa just released version 3.0.4 of Ganglia. This is mainly a bugfix release. See the ChangeLog in the tarball for a complete list of changes. Updated Fedora Extras builds for rawhide, FC6 and FC5 coming shortly... -- Jarod Wilson [EMAIL PROTECTED] pgp1vtOGfoCA4.pgp Description: PGP signature
Re: [Ganglia-developers] Correct counting of CPUs, Cores, Siblings (bz #84)
On Friday 22 December 2006 11:05, Martin Knoblauch wrote: Hi Folks, in order to fix bz#84 for Linux, I would like to collect some data from different system configurations. Could you please create the file cpu.grep and execute the cat/grep chain below. Please report the results together with uname -a output which distro you are running. # more cpu.grep processor vendor model name physical id siblings core id cpu cores # cat /proc/cpuinfo | grep -f cpu.grep Here's the data from my Fedora Core 6 workstation in the office, since its fairly interesting for this specific topic. Its a dual-socket, dual-core Xeon system with hyperthreading turned on, so two sockets, four cores, eight logical cpus... Linux xavier.boston.redhat.com 2.6.18-1.2849.fc6 #1 SMP Fri Nov 10 12:34:46 EST 2006 x86_64 x86_64 x86_64 GNU/Linux processor : 0 vendor_id : GenuineIntel model name : Intel(R) Xeon(TM) CPU 3.00GHz physical id : 0 siblings: 4 core id : 0 cpu cores : 2 processor : 1 vendor_id : GenuineIntel model name : Intel(R) Xeon(TM) CPU 3.00GHz physical id : 1 siblings: 4 core id : 0 cpu cores : 2 processor : 2 vendor_id : GenuineIntel model name : Intel(R) Xeon(TM) CPU 3.00GHz physical id : 0 siblings: 4 core id : 1 cpu cores : 2 processor : 3 vendor_id : GenuineIntel model name : Intel(R) Xeon(TM) CPU 3.00GHz physical id : 1 siblings: 4 core id : 1 cpu cores : 2 processor : 4 vendor_id : GenuineIntel model name : Intel(R) Xeon(TM) CPU 3.00GHz physical id : 0 siblings: 4 core id : 0 cpu cores : 2 processor : 5 vendor_id : GenuineIntel model name : Intel(R) Xeon(TM) CPU 3.00GHz physical id : 1 siblings: 4 core id : 0 cpu cores : 2 processor : 6 vendor_id : GenuineIntel model name : Intel(R) Xeon(TM) CPU 3.00GHz physical id : 0 siblings: 4 core id : 1 cpu cores : 2 processor : 7 vendor_id : GenuineIntel model name : Intel(R) Xeon(TM) CPU 3.00GHz physical id : 1 siblings: 4 core id : 1 cpu cores : 2 -- Jarod Wilson [EMAIL PROTECTED] pgpnbKNbfBGo8.pgp Description: PGP signature
Re: [Ganglia-developers] apr, expat, confuse asshipped with ganglia
On Thu, 2006-08-17 at 15:46 +0200, Marcus Rueckert wrote: hi, while we are looking into dependencies: APR 1.x is out since quite some time and should solve many bugs. is anyone working on that already? We're shipping apr 1.2.7 with Fedora Core 6 and RHEL5. FC5 shipped apr 1.2.2. Looks like 0.9.x for FC3/FC4/RHEL4. another nice thing is that most old systems only ship apr0. so you can easily provide addon packages with apr1 and the removing the intree libraries might not hurt as much there. It gets a little fun in RH/FC, since we simply ship apr (no libversion attached), but yeah, the same can still be done w/an apr and a compat-apr. -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: [Ganglia-developers] apr, expat, confuse asshipped with ganglia
On Thu, 2006-08-17 at 16:11 +0200, Marcus Rueckert wrote: On 2006-08-17 09:55:38 -0400, Jarod Wilson wrote: On Thu, 2006-08-17 at 15:46 +0200, Marcus Rueckert wrote: hi, while we are looking into dependencies: APR 1.x is out since quite some time and should solve many bugs. is anyone working on that already? We're shipping apr 1.2.7 with Fedora Core 6 and RHEL5. FC5 shipped apr 1.2.2. Looks like 0.9.x for FC3/FC4/RHEL4. another nice thing is that most old systems only ship apr0. so you can easily provide addon packages with apr1 and the removing the intree libraries might not hurt as much there. It gets a little fun in RH/FC, since we simply ship apr (no libversion attached), but yeah, the same can still be done w/an apr and a compat-apr. or just name the new rpms (lib)apr1 and avoid the trouble atall. i mean they are unofficial/unsupported? rpms only anyway. no?:) I s'pose you could do that too. :) -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: [Ganglia-developers] apr, expat, confuse asshipped with ganglia
On Thu, 2006-08-17 at 16:40 +0200, Marcus Rueckert wrote:
On 2006-08-17 10:20:16 -0400, Jarod Wilson wrote:
On Thu, 2006-08-17 at 16:11 +0200, Marcus Rueckert wrote:
On 2006-08-17 09:55:38 -0400, Jarod Wilson wrote:
On Thu, 2006-08-17 at 15:46 +0200, Marcus Rueckert wrote:
hi,
while we are looking into dependencies:
APR 1.x is out since quite some time and should solve many bugs.
is anyone working on that already?
We're shipping apr 1.2.7 with Fedora Core 6 and RHEL5. FC5 shipped apr
1.2.2. Looks like 0.9.x for FC3/FC4/RHEL4.
another nice thing is that most old systems only ship apr0. so you can
easily provide addon packages with apr1 and the removing the intree
libraries might not hurt as much there.
It gets a little fun in RH/FC, since we simply ship apr (no libversion
attached), but yeah, the same can still be done w/an apr and a
compat-apr.
or just name the new rpms (lib)apr1 and avoid the trouble atall. i mean
they are unofficial/unsupported? rpms only anyway. no?:)
I s'pose you could do that too. :)
guess why i was pushing towards apr1. ;)
I think I had my official Red Hat hat on... We typically do $package and
compat-$package, rather than lib${package}${libver}. :p (though note
that I personally actually like the latter method better...)
--
Jarod Wilson
[EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
Re: [Ganglia-developers] apr, expat, confuse as shipped with ganglia
On Wed, 2006-08-16 at 06:13 -0700, Martin Knoblauch wrote: Hi Bernard, as I said, if nobody is hurt :-) Being curious I did a quick check on my favourite distribution (FC4, yum-uptodate): - apr/apr-devel is 0.9.6-3.5, which is older that what we ship (0.9.7) - expat/expat-devel is 1.95.8-6, which is better thatn what we ship (1.95.1) - libconfuse/libconfuse-devel does not seem to exist. Only RPMs I found are for Mandrake/Mandriva and are version 2.1, which is way older than what we ship (2.5) Seems we are safe for expat, need to check apr and are kind of lost for libconfuse. I can see about packaging the latest libconfuse for Fedora. However, without a special exception, it won't be built for FC4, as FC4 has entered 'maintenance mode' (meaning generally nothing new gets built, only fixes for existing packages allowed). [...time passes...] Almost there with a package that I think will pass Fedora Extras muster... -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: [Ganglia-developers] apr, expat, confuse as shipped with ganglia
On Wed, 2006-08-16 at 08:34 -0700, Martin Knoblauch wrote: --- Jarod Wilson [EMAIL PROTECTED] wrote: Seems we are safe for expat, need to check apr and are kind of lost for libconfuse. I can see about packaging the latest libconfuse for Fedora. However, without a special exception, it won't be built for FC4, as FC4 has entered 'maintenance mode' (meaning generally nothing new gets built, only fixes for existing packages allowed). [...time passes...] Almost there with a package that I think will pass Fedora Extras muster... cool :-) But given the fact that libconfuse RPMs are really really rare, it was not was I were asking for. How about just build against distro-provided libconfuse if it exists, use included version if it doesn't? More or less what Marcus said: i can tell you that there should be at least an option to say --with-$lib=/usr so it will use the system wide copy. -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: [Ganglia-developers] apr, expat, confuse as shipped with ganglia
On Wed, 2006-08-16 at 10:16 -0400, Jarod Wilson wrote: I can see about packaging the latest libconfuse for Fedora. However, without a special exception, it won't be built for FC4, as FC4 has entered 'maintenance mode' (meaning generally nothing new gets built, only fixes for existing packages allowed). [...time passes...] Almost there with a package that I think will pass Fedora Extras muster... Just submitted it for Fedora Extras review: https://bugzilla.redhat.com/202820/ -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: [Ganglia-developers] apr, expat, confuse asshipped with ganglia
On Wed, 2006-08-16 at 11:42 -0700, Bernard Li wrote: Hi Jarod: Great - let's hope it gets accepted soon :-) This has to be some sort of Fedora Extras record for shortest time waiting on acceptance. Its been approved, and is being built for the development tree as I type, with a branch for FC5 pending. No FC4 branch, unless there's a compelling argument for it -- might be possible if ganglia were to need a rebuild using it... Marcus, is there a RPM for SUSE? There's a spec included in the confuse tarball that is heavily tailored for SUSE, so I'm guessing yes. Stu, how about for Debian...? From what I can see, its available in Debian repos. I believe it was mentioned that there is already one for Mandriva... Someone mentioned finding a v2.1 Mandriva package, which is quite ancient (even the latest, v2.5, is nearly 2 years old). -Original Message- From: Jarod Wilson [mailto:[EMAIL PROTECTED] Sent: Wed 16/08/2006 10:56 To: Bernard Li Cc: ganglia-developers@lists.sourceforge.net Subject: RE: [Ganglia-developers] apr, expat, confuse asshipped with ganglia On Wed, 2006-08-16 at 10:43 -0700, Bernard Li wrote: Says 404 for me... Bah, what the heck, who broke the redirectors... Okay, full link, this works, I promise: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=202820 BTW, I don't suppose there'll be any chance for it to get into RHEL5...? Highly unlikely at this point in the game, barring it being requested by a (probably major) customer... -Original Message- From: [EMAIL PROTECTED] on behalf of Jarod Wilson Sent: Wed 16/08/2006 09:28 To: ganglia-developers@lists.sourceforge.net Subject: Re: [Ganglia-developers] apr, expat, confuse as shipped withganglia On Wed, 2006-08-16 at 10:16 -0400, Jarod Wilson wrote: I can see about packaging the latest libconfuse for Fedora. However, without a special exception, it won't be built for FC4, as FC4 has entered 'maintenance mode' (meaning generally nothing new gets built, only fixes for existing packages allowed). [...time passes...] Almost there with a package that I think will pass Fedora Extras muster... Just submitted it for Fedora Extras review: https://bugzilla.redhat.com/202820/ -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: [Ganglia-developers] apr, expat, confuse asshipped with ganglia
On Wed, 2006-08-16 at 21:50 +0100, Stu Teasdale wrote: On Wed, Aug 16, 2006 at 04:18:46PM -0400, Jarod Wilson wrote: Stu, how about for Debian...? From what I can see, its available in Debian repos. They're 2.5.x packages unfortunately. I have 3.0.3 packages, but a couiple of outstanding issues (stopping libtool from spraying rpaths around and a file in the metrics directory lifted from glibc and therefore GPLed) have thus far blocked me from uploading. I thought we were only talking about libconfuse at this point... Interesting to know about the heisted GPL file though. As for the rpath fun, I've had to deal with that for a number of Fedora packages, but haven't encountered any with ganglia (or at least I don't see any hacks to deal with them in my spec, and rpmlint says there aren't any). -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: [Ganglia-developers] apr, expat, confuse as shipped with ganglia
On Sat, 2006-08-12 at 15:41 -0700, Bernard Li wrote: Hi all: In discussion with Marcus Rueckert (SUSE Linux packager), he suggested a solution which the subversion folks are doing in their latest 1.4.0 RC - to ship dependencies in a separate tarball. This way, for Linux packagers, we only need the core tarball and will not include the dependencies, then we can simply link against whatever the distro provides. I think this is a good solution and will eliminate headaches for package maintainers of the various distroes. Just to confirm, that works nicely for Red Hat and Fedora too. -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: [Ganglia-developers] apr, expat, confuse as shipped with ganglia
On Mon, 2006-08-14 at 11:04 -0700, Bernard Li wrote: I think most people like this idea (Martin, Matt??) - so I think we can start thinking about how to modify the configure/make system. Jarod, have you already done some work on this front? No, I haven't really looked at it yet, currently buried in xen, kexec and ext4 fun... I just know using distro-provided libs is definitely preferred in Red Hat land. :) -Original Message- From: [EMAIL PROTECTED] on behalf of Jarod Wilson Sent: Mon 14/08/2006 10:42 To: ganglia-developers@lists.sourceforge.net Subject: Re: [Ganglia-developers] apr, expat, confuse as shipped with ganglia On Sat, 2006-08-12 at 15:41 -0700, Bernard Li wrote: Hi all: In discussion with Marcus Rueckert (SUSE Linux packager), he suggested a solution which the subversion folks are doing in their latest 1.4.0 RC - to ship dependencies in a separate tarball. This way, for Linux packagers, we only need the core tarball and will not include the dependencies, then we can simply link against whatever the distro provides. I think this is a good solution and will eliminate headaches for package maintainers of the various distroes. Just to confirm, that works nicely for Red Hat and Fedora too. -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: [Ganglia-developers] regarding graphic display of ganglia-webfrontend
On Aug 01, 2006, at 09:21, Rajendar K wrote: Hi, I have configured ganglia 3.0.3 with gmetad and when i tried out to view ganglia-webfrontend (http://localhost/ganglia) , iam unable to see the graph display, . Any solution regarding this? Look in your web logs for clues. Perhaps you're missing some needed rrdtool bits. -- Jarod Wilson [EMAIL PROTECTED]
[Ganglia-developers] ganglia spec file maintenance
As I understand it, there's an upstream ganglia spec file, one maintained by a SUSE packager, and the one I'm now maintaining for Fedora Extras (and quite possibly specs for other rpm-based distros). At the suggestion of Bernard Li, who maintains the upstream spec, I thought we could start some discourse on how we might reduce the number of spec files, or at least strive for more consistency. Note that Fedora has some fairly stringent packaging guidelines (http://fedoraproject.org/wiki/Packaging/Guidelines and http://fedoraproject.org/wiki/PackageReviewGuidelines, among other pages). While I started out with the upstream spec as a base to get ganglia into Fedora Extras, I ended up scrapping it and rewriting from scratch, due to the volume of change required to meet Fedora guidelines. Now the diff between the upstream spec and my spec is now more than two times the length of either spec. :\ For reference, my spec can be seen here: http://wilsonet.com/packages/ganglia/ganglia.spec -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
