[Ganglia-developers] releasing 3.3.2 with make dist - missing files
I tried `make dist' for a possible 3.3.2 release, there are some differences in the fileset I don't think all of them are essential to the release, but I'm publishing it here so people can have a quick look and make any comments I already notice the web/.git stuff - I'll exclude that from the tarball --- /tmp/331.list 2012-03-20 12:53:34.0 +0100 +++ /tmp/332.list 2012-03-20 12:53:29.0 +0100 @@ -2,7 +2,6 @@ acinclude.m4 aclocal.m4 AUTHORS -bootstrap BUGS build/ build/config.guess @@ -25,67 +24,8 @@ contrib/README-removespikes contrib/removespikes.pl COPYING -debian/ -debian/apache.conf -debian/changelog -debian/compat -debian/conf_redirect.php -debian/control -debian/copyright -debian/docs -debian/ganglia-monitor.dirs -debian/ganglia-monitor.docs -debian/ganglia-monitor.init -debian/ganglia-monitor.install -debian/ganglia-monitor.manpages -debian/ganglia-monitor.postinst -debian/ganglia-monitor.postrm -debian/ganglia-monitor-python.dirs -debian/ganglia-webfrontend.config -debian/ganglia-webfrontend.dirs -debian/ganglia-webfrontend.postinst -debian/ganglia-webfrontend.postrm -debian/ganglia-webfrontend.templates -debian/gmetad.conf -debian/gmetad.dirs -debian/gmetad.init -debian/gmetad.install -debian/gmetad.manpages -debian/gmetad.postinst -debian/gmetad.postrm -debian/gmond.conf -debian/libganglia1-dev.dirs -debian/libganglia1-dev.install -debian/libganglia1-dev.manpages -debian/libganglia1.dirs -debian/libganglia1.install -debian/modpython.conf -debian/patches/ -debian/patches/debian-changes-3.1.7-2 -debian/patches/series -debian/po/ -debian/po/cs.po -debian/po/da.po -debian/po/de.po -debian/po/es.po -debian/po/et.po -debian/po/eu.po -debian/po/fi.po -debian/po/fr.po -debian/po/gl.po -debian/po/it.po -debian/po/ja.po -debian/po/POTFILES.in -debian/po/pt.po -debian/po/ru.po -debian/po/sv.po -debian/po/templates.pot -debian/po/vi.po -debian/README.Debian -debian/rules -debian/source/ -debian/source/format ganglia-config.in +ganglia.html ganglia.inc ganglia.pod ganglia.spec @@ -93,9 +33,10 @@ ganglia.spec.in gmetad/ gmetad/cleanup.c +gmetad/cmdline.c gmetad/cmdline.c.in gmetad/cmdline.h -gmetad/cmdline.sh +gmetad/conf.c gmetad/conf.c.in gmetad/conf.h gmetad/daemon_init.c @@ -110,11 +51,11 @@ gmetad/gmetad.init.SuSE gmetad/Makefile.am gmetad/Makefile.in -gmetad/metric_hash.c gmetad/process_xml.c gmetad-python/ gmetad-python/Gmetad/ gmetad-python/gmetad_consistency_test.py +gmetad-python/Gmetad/gmetad_config.py gmetad-python/Gmetad/gmetad_config.py.in gmetad-python/Gmetad/gmetad_daemon.py gmetad-python/Gmetad/gmetad_data.py @@ -126,12 +67,15 @@ gmetad-python/Gmetad/gmetad_xmlWriter.py gmetad-python/Gmetad/__init__.py gmetad-python/gmetad.py +gmetad-python/gmetad-python.conf gmetad-python/gmetad-python.conf.in gmetad-python/plugins/ gmetad-python/plugins/alert_plugin.py.off +gmetad-python/plugins/rrd_plugin.py gmetad-python/plugins/rrd_plugin.py.in gmetad-python/plugins/rrd_summary_plugin.py gmetad-python/README +gmetad-python/setup.py gmetad-python/setup.py.in gmetad-python/TODO gmetad/rrd_helpers.c @@ -142,16 +86,16 @@ gmetad/xml_hash.c gmetad/xml_hash.gperf gmetric/ +gmetric/cmdline.c gmetric/cmdline.c.in gmetric/cmdline.h -gmetric/cmdline.sh gmetric/gmetric.c gmetric/Makefile.am gmetric/Makefile.in gmond/ +gmond/cmdline.c gmond/cmdline.c.in gmond/cmdline.h -gmond/cmdline.sh gmond/conf.pod gmond/core_metrics.c gmond/dtd.h @@ -159,6 +103,8 @@ gmond/g25_config.h gmond/gmond.aix.init gmond/gmond.c +gmond/gmond.conf.5 +gmond/gmond.conf.html gmond/gmond.init gmond/gmond.init.SuSE gmond/gmond_internal.h @@ -199,6 +145,7 @@ gmond/modules/python/Makefile.am gmond/modules/python/Makefile.in gmond/modules/python/mod_python.c +gmond/modules/python/README gmond/modules/python/README.in gmond/modules/status/ gmond/modules/status/Makefile.am @@ -210,8 +157,6 @@ gmond/modules/system/mod_proc.c gmond/modules/system/mod_sys.c gmond/python_modules/ -gmond/python_modules/apache_status/ -gmond/python_modules/apache_status/apache_status.py gmond/python_modules/conf.d/ gmond/python_modules/conf.d/apache_status.pyconf.disabled gmond/python_modules/conf.d/diskfree.pyconf @@ -221,7 +166,7 @@ gmond/python_modules/conf.d/example.pyconf.disabled gmond/python_modules/conf.d/memcached.pyconf.disabled gmond/python_modules/conf.d/mem_stats.pyconf -gmond/python_modules/conf.d/multi_traffic.pyconf +gmond/python_modules/conf.d/multi_interface.pyconf gmond/python_modules/conf.d/mysql.pyconf.disabled gmond/python_modules/conf.d/netstats.pyconf gmond/python_modules/conf.d/nfsstats.pyconf.disabled @@ -243,7 +188,6 @@ gmond/python_modules/db/riak.py gmond/python_modules/disk/ gmond/python_modules/disk/diskfree.py -gmond/python_modules/disk/diskstat.py gmond/python_modules/disk/Makefile.am gmond/python_modules/disk/Makefile.in
[Ganglia-developers] releasing 3.3.2 today?
I've updated the document at https://github.com/ganglia/monitor-core/wiki/BuildingARelease and been able to follow the steps there to build a working tarball (at least the tarball works for me). The main change is that it now relies on `make dist' rather than scripts/package-ganglia-release to decide what belongs in the tarball. Does anyone want to sneak in any last minute changes before I tag 3.3.2 and make the tarball available for testing? Where should I put the tarball for people to test before general release? -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] releasing 3.3.2 with make dist - missing files
On 20/03/2012 11:54, Daniel Pocock wrote: I tried `make dist' for a possible 3.3.2 release, there are some differences in the fileset I don't think all of them are essential to the release, but I'm publishing it here so people can have a quick look and make any comments I already notice the web/.git stuff - I'll exclude that from the tarball I've now fixed that and some other things, so it should be easier to read the diff - revised diff below A script for comparing tarballs is in the scripts/ directory for anyone who needs to run this themself --- ganglia-3.3.1.tar.gz.file-list 2012-03-20 14:58:37.0 +0100 +++ ganglia-3.3.2.tar.gz.file-list 2012-03-20 14:58:37.0 +0100 @@ -25,67 +25,8 @@ contrib/README-removespikes contrib/removespikes.pl COPYING -debian/ -debian/apache.conf -debian/changelog -debian/compat -debian/conf_redirect.php -debian/control -debian/copyright -debian/docs -debian/ganglia-monitor.dirs -debian/ganglia-monitor.docs -debian/ganglia-monitor.init -debian/ganglia-monitor.install -debian/ganglia-monitor.manpages -debian/ganglia-monitor.postinst -debian/ganglia-monitor.postrm -debian/ganglia-monitor-python.dirs -debian/ganglia-webfrontend.config -debian/ganglia-webfrontend.dirs -debian/ganglia-webfrontend.postinst -debian/ganglia-webfrontend.postrm -debian/ganglia-webfrontend.templates -debian/gmetad.conf -debian/gmetad.dirs -debian/gmetad.init -debian/gmetad.install -debian/gmetad.manpages -debian/gmetad.postinst -debian/gmetad.postrm -debian/gmond.conf -debian/libganglia1-dev.dirs -debian/libganglia1-dev.install -debian/libganglia1-dev.manpages -debian/libganglia1.dirs -debian/libganglia1.install -debian/modpython.conf -debian/patches/ -debian/patches/debian-changes-3.1.7-2 -debian/patches/series -debian/po/ -debian/po/cs.po -debian/po/da.po -debian/po/de.po -debian/po/es.po -debian/po/et.po -debian/po/eu.po -debian/po/fi.po -debian/po/fr.po -debian/po/gl.po -debian/po/it.po -debian/po/ja.po -debian/po/POTFILES.in -debian/po/pt.po -debian/po/ru.po -debian/po/sv.po -debian/po/templates.pot -debian/po/vi.po -debian/README.Debian -debian/rules -debian/source/ -debian/source/format ganglia-config.in +ganglia.html ganglia.inc ganglia.pod ganglia.spec @@ -93,9 +34,11 @@ ganglia.spec.in gmetad/ gmetad/cleanup.c +gmetad/cmdline.c gmetad/cmdline.c.in gmetad/cmdline.h gmetad/cmdline.sh +gmetad/conf.c gmetad/conf.c.in gmetad/conf.h gmetad/daemon_init.c @@ -110,11 +53,11 @@ gmetad/gmetad.init.SuSE gmetad/Makefile.am gmetad/Makefile.in -gmetad/metric_hash.c gmetad/process_xml.c gmetad-python/ gmetad-python/Gmetad/ gmetad-python/gmetad_consistency_test.py +gmetad-python/Gmetad/gmetad_config.py gmetad-python/Gmetad/gmetad_config.py.in gmetad-python/Gmetad/gmetad_daemon.py gmetad-python/Gmetad/gmetad_data.py @@ -126,12 +69,15 @@ gmetad-python/Gmetad/gmetad_xmlWriter.py gmetad-python/Gmetad/__init__.py gmetad-python/gmetad.py +gmetad-python/gmetad-python.conf gmetad-python/gmetad-python.conf.in gmetad-python/plugins/ gmetad-python/plugins/alert_plugin.py.off +gmetad-python/plugins/rrd_plugin.py gmetad-python/plugins/rrd_plugin.py.in gmetad-python/plugins/rrd_summary_plugin.py gmetad-python/README +gmetad-python/setup.py gmetad-python/setup.py.in gmetad-python/TODO gmetad/rrd_helpers.c @@ -142,6 +88,7 @@ gmetad/xml_hash.c gmetad/xml_hash.gperf gmetric/ +gmetric/cmdline.c gmetric/cmdline.c.in gmetric/cmdline.h gmetric/cmdline.sh @@ -149,6 +96,7 @@ gmetric/Makefile.am gmetric/Makefile.in gmond/ +gmond/cmdline.c gmond/cmdline.c.in gmond/cmdline.h gmond/cmdline.sh @@ -159,6 +107,8 @@ gmond/g25_config.h gmond/gmond.aix.init gmond/gmond.c +gmond/gmond.conf.5 +gmond/gmond.conf.html gmond/gmond.init gmond/gmond.init.SuSE gmond/gmond_internal.h @@ -199,6 +149,7 @@ gmond/modules/python/Makefile.am gmond/modules/python/Makefile.in gmond/modules/python/mod_python.c +gmond/modules/python/README gmond/modules/python/README.in gmond/modules/status/ gmond/modules/status/Makefile.am @@ -212,6 +163,8 @@ gmond/python_modules/ gmond/python_modules/apache_status/ gmond/python_modules/apache_status/apache_status.py +gmond/python_modules/apache_status/Makefile.am +gmond/python_modules/apache_status/Makefile.in gmond/python_modules/conf.d/ gmond/python_modules/conf.d/apache_status.pyconf.disabled gmond/python_modules/conf.d/diskfree.pyconf @@ -221,7 +174,7 @@ gmond/python_modules/conf.d/example.pyconf.disabled gmond/python_modules/conf.d/memcached.pyconf.disabled gmond/python_modules/conf.d/mem_stats.pyconf -gmond/python_modules/conf.d/multi_traffic.pyconf +gmond/python_modules/conf.d/multi_interface.pyconf gmond/python_modules/conf.d/mysql.pyconf.disabled gmond/python_modules/conf.d/netstats.pyconf gmond/python_modules/conf.d/nfsstats.pyconf.disabled @@ -259,17 +212,20 @@ gmond/python_modules/memcached/Makefile.in
Re: [Ganglia-developers] releasing 3.3.2 today?
On 20/03/2012 12:09, Daniel Pocock wrote: I've updated the document at https://github.com/ganglia/monitor-core/wiki/BuildingARelease and been able to follow the steps there to build a working tarball (at least the tarball works for me). The main change is that it now relies on `make dist' rather than scripts/package-ganglia-release to decide what belongs in the tarball. Does anyone want to sneak in any last minute changes before I tag 3.3.2 and make the tarball available for testing? Where should I put the tarball for people to test before general release? I've put a pre-release tarball here: https://sourceforge.net/projects/ganglia/files/pre-release/ It is based on commit e59f87da325bf66d128b086054656ec280b200e2 which has not yet been tagged If there are no loud objections, I'll tag it later today The SHA-256 checksum for this tarball is: 10c587b2f913c47b1ed06e7d00c33192604fe4bf2b3ad113d67abf178b241972 -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] releasing 3.3.2 today?
I tested the tarball and it still does not contain the following files: ganglia-3.3.2/ChangeLog ganglia-3.3.2/libmetrics/ChangeLog ganglia-3.3.2/libmetrics/INSTALL Those files are necessary if you do a autoreconf -fi which is necessary if you add something to any *.am file in the source tree. I build all the additional gmond modules for AIX and Linux on Power this way. Therefore, I have in the respective spec-file a statement like this in %prep: %prep %setup -q # autoreconf seems to need this one touch ChangeLog libmetrics/ChangeLog libmetrics/INSTALL I have verified this and get the exact same behavior on all platforms that I use which include: AIX 5.1, AIX 5.3, SLES9, SLES10, SLES11, RHEL4, RHEL6 So I assume this is nothing specific to AIX but a general issue. Ganglia version 3.3.1 was the first one where this is required, any previous version did not requires this. Before you release version 3.3.2 could you please add (dummy) files for those? Regards, Michael On 03/20/2012 03:07 PM, Daniel Pocock wrote: On 20/03/2012 12:09, Daniel Pocock wrote: I've updated the document at https://github.com/ganglia/monitor-core/wiki/BuildingARelease and been able to follow the steps there to build a working tarball (at least the tarball works for me). The main change is that it now relies on `make dist' rather than scripts/package-ganglia-release to decide what belongs in the tarball. Does anyone want to sneak in any last minute changes before I tag 3.3.2 and make the tarball available for testing? Where should I put the tarball for people to test before general release? I've put a pre-release tarball here: https://sourceforge.net/projects/ganglia/files/pre-release/ It is based on commit e59f87da325bf66d128b086054656ec280b200e2 which has not yet been tagged If there are no loud objections, I'll tag it later today The SHA-256 checksum for this tarball is: 10c587b2f913c47b1ed06e7d00c33192604fe4bf2b3ad113d67abf178b241972 -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] releasing 3.3.2 today?
Besides the autoreconf issue I mentioned in my previous email, the tarball compiles cleanly on AIX5.1, AIX5.3, RHEL4, RHEL6, SLES9, SLES10, SLES11 Regards, Michael On 03/20/2012 03:07 PM, Daniel Pocock wrote: On 20/03/2012 12:09, Daniel Pocock wrote: I've updated the document at https://github.com/ganglia/monitor-core/wiki/BuildingARelease and been able to follow the steps there to build a working tarball (at least the tarball works for me). The main change is that it now relies on `make dist' rather than scripts/package-ganglia-release to decide what belongs in the tarball. Does anyone want to sneak in any last minute changes before I tag 3.3.2 and make the tarball available for testing? Where should I put the tarball for people to test before general release? I've put a pre-release tarball here: https://sourceforge.net/projects/ganglia/files/pre-release/ It is based on commit e59f87da325bf66d128b086054656ec280b200e2 which has not yet been tagged If there are no loud objections, I'll tag it later today The SHA-256 checksum for this tarball is: 10c587b2f913c47b1ed06e7d00c33192604fe4bf2b3ad113d67abf178b241972 -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] releasing 3.3.2 today?
Hi Daniel: If you let me know where you put the tarballs I will put them in http://ganglia.info/downloads/testing. Cheers, Bernard On Tuesday, March 20, 2012, Daniel Pocock dan...@pocock.com.au wrote: I've updated the document at https://github.com/ganglia/monitor-core/wiki/BuildingARelease and been able to follow the steps there to build a working tarball (at least the tarball works for me). The main change is that it now relies on `make dist' rather than scripts/package-ganglia-release to decide what belongs in the tarball. Does anyone want to sneak in any last minute changes before I tag 3.3.2 and make the tarball available for testing? Where should I put the tarball for people to test before general release? -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] releasing 3.3.2 today?
On Tue, Mar 20, 2012 at 12:09:29PM +, Daniel Pocock wrote: Does anyone want to sneak in any last minute changes before I tag 3.3.2 and make the tarball available for testing? there is already a published tag named 3.3.2, if you are not going to release that then it will be better if we skip that release number and aim for 3.3.3 would recommend for testing you do tag it like 3.3.2pre1 or something like that as well. Carlo -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] releasing 3.3.2 today?
Thanks for the prompt feedback I understand from your email that you are not worried if those files are empty? Maintaining extra copies of these files for libmetrics may be another reason to try and avoid the nested configure script On 20/03/2012 15:07, Michael Perzl wrote: I tested the tarball and it still does not contain the following files: ganglia-3.3.2/ChangeLog ganglia-3.3.2/libmetrics/ChangeLog ganglia-3.3.2/libmetrics/INSTALL Those files are necessary if you do a autoreconf -fi which is necessary if you add something to any *.am file in the source tree. I build all the additional gmond modules for AIX and Linux on Power this way. Therefore, I have in the respective spec-file a statement like this in %prep: %prep %setup -q # autoreconf seems to need this one touch ChangeLog libmetrics/ChangeLog libmetrics/INSTALL I have verified this and get the exact same behavior on all platforms that I use which include: AIX 5.1, AIX 5.3, SLES9, SLES10, SLES11, RHEL4, RHEL6 So I assume this is nothing specific to AIX but a general issue. Ganglia version 3.3.1 was the first one where this is required, any previous version did not requires this. Before you release version 3.3.2 could you please add (dummy) files for those? Regards, Michael On 03/20/2012 03:07 PM, Daniel Pocock wrote: On 20/03/2012 12:09, Daniel Pocock wrote: I've updated the document at https://github.com/ganglia/monitor-core/wiki/BuildingARelease and been able to follow the steps there to build a working tarball (at least the tarball works for me). The main change is that it now relies on `make dist' rather than scripts/package-ganglia-release to decide what belongs in the tarball. Does anyone want to sneak in any last minute changes before I tag 3.3.2 and make the tarball available for testing? Where should I put the tarball for people to test before general release? I've put a pre-release tarball here: https://sourceforge.net/projects/ganglia/files/pre-release/ It is based on commit e59f87da325bf66d128b086054656ec280b200e2 which has not yet been tagged If there are no loud objections, I'll tag it later today The SHA-256 checksum for this tarball is: 10c587b2f913c47b1ed06e7d00c33192604fe4bf2b3ad113d67abf178b241972 -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] releasing 3.3.2 today?
On 20/03/2012 16:32, Carlo Marcelo Arenas Belon wrote: On Tue, Mar 20, 2012 at 12:09:29PM +, Daniel Pocock wrote: Does anyone want to sneak in any last minute changes before I tag 3.3.2 and make the tarball available for testing? there is already a published tag named 3.3.2, if you are not going to release that then it will be better if we skip that release number and aim for 3.3.3 I can see that 3.3.2 exists and there are changes since that tag too, so it is not a good one to release. We will not make a real 3.3.2 release then. 3.3.3 is the new 3.3.2 would recommend for testing you do tag it like 3.3.2pre1 or something like that as well. I agree with that approach, with a slight variation - I'll tag it as 3.3.3dp1 (after adding the ChangeLog file) I will tag the same commit as 3.3.3 if it passes QA (two tags can point to the same commit in the world of git) -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
[Ganglia-developers] re-bootstrapping Ganglia
Michael's request for ChangeLog and INSTALL files mentions a requirement to re-bootstrap the source tree (using autoreconf to regenerate Makefiles) Some time ago we had a discussion where it was decided that the autotools product versions in Debian 6.0 (squeeze) would be the official platform for bootstrapping Ganglia releases. However, if people do need to bootstrap on other platforms, they may hit problems (such as those encountered by Michael) A few things some to mind: a) as I'm no longer in a position to make all the releases, are other people happy to continue with Debian 6.0 autotools? I believe the platform is well known and widely available, and it is not something that should be changed during the 3.3.x release series, but it is not my decision. b) should Michael (or anyone else) need to modify Makefile.am from a tarball? If there are regular changes to Makefile.am after releases are made, shouldn't we find a way to incorporate such changes into trunk, or provide more variables for people to set things at build time? c) Do we want to start maintaining a ChangeLog file again? I remember change log data used to be kept in one of the text files, was it README? -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] releasing 3.3.2 today?
On Tue, Mar 20, 2012 at 10:03 AM, Daniel Pocock dan...@pocock.com.au wrote: I agree with that approach, with a slight variation - I'll tag it as 3.3.3dp1 (after adding the ChangeLog file) Quick question -- does this prevent RPM upgrading? i.e. 3.3.3dp1 - 3.3.3? Cheers, Bernard -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] releasing 3.3.2 today?
On 20/03/2012 17:34, Bernard Li wrote: On Tue, Mar 20, 2012 at 10:03 AM, Daniel Pocockdan...@pocock.com.au wrote: I agree with that approach, with a slight variation - I'll tag it as 3.3.3dp1 (after adding the ChangeLog file) Quick question -- does this prevent RPM upgrading? i.e. 3.3.3dp1 - 3.3.3? It is just a tag to help us keep track of what we test, it is not intended for versioning a binary package However, if we want to be able to version binary packages using release candidates, we may need to look at the problem more closely -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
[Ganglia-developers] 3.3.3dp1 release candidate
I've tagged a release candidate 3.3.3dp1 commit = c8531e5d57f6126eee6f47f1ad8734e86c1e9cb5 SHA-256 96cd90f2f978bb5e6c471798fa8d4b599a9910dfdae19bbfd7353abcb1497548 ganglia-3.3.3.tar.gz The two changes from 3.3.2: a) we are no longer calling it 3.3.2, because a tag already exists with that name b) created and added artefacts requested by Michael I've put it in the pre-release section on Sourceforge: https://sourceforge.net/projects/ganglia/files/pre-release/ Bernard, can you copy it to the page you mentioned, or let me know how to do this in future? If the release candidate is accepted, then we simply need to tag the same commit as the official 3.3.3 tag git checkout 3.3.3dp1 \ git tag -s -m 'Tag final 3.3.3 release' 3.3.3 and advertise it as official in the usual way. This was created using the procedure here: https://github.com/ganglia/monitor-core/wiki/BuildingARelease - it would be interesting to know if anyone else can verify that the procedure is acceptable, make sure that I've added enough detail for anyone else to repeat it Regards, Daniel -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] releasing 3.3.2 today?
On Tue, Mar 20, 2012 at 05:36:56PM +, Daniel Pocock wrote: On 20/03/2012 17:34, Bernard Li wrote: On Tue, Mar 20, 2012 at 10:03 AM, Daniel Pocockdan...@pocock.com.au wrote: I agree with that approach, with a slight variation - I'll tag it as 3.3.3dp1 (after adding the ChangeLog file) Quick question -- does this prevent RPM upgrading? i.e. 3.3.3dp1 - 3.3.3? It is just a tag to help us keep track of what we test, it is not intended for versioning a binary package AFAIK the version of this release will be 3.3.2 since micro numbers no longer exist. Carlo -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] releasing 3.3.2 today?
On Tue, Mar 20, 2012 at 13:36, Daniel Pocock dan...@pocock.com.au wrote: On 20/03/2012 17:34, Bernard Li wrote: On Tue, Mar 20, 2012 at 10:03 AM, Daniel Pocockdan...@pocock.com.au wrote: I agree with that approach, with a slight variation - I'll tag it as 3.3.3dp1 (after adding the ChangeLog file) Quick question -- does this prevent RPM upgrading? i.e. 3.3.3dp1 - 3.3.3? It is just a tag to help us keep track of what we test, it is not intended for versioning a binary package However, if we want to be able to version binary packages using release candidates, we may need to look at the problem more closely It matters very much for RPM packages, and I suspect debian packages as well (although I don't know the details of building those). RPMs inherently understand version numbers, and that 3.3.2 is a more recent release than 3.3.1. There are some further syntactic bits added in, such as package release numbers (which are essentially, the least significant digit in the version), but the version number matters a great deal. I think that versions such as 3.3.3pre1, 3.3.3pre2 and 3.3.3 are handled correctly. These pages details the issue: http://fedoraproject.org/wiki/Tools/RPM/VersionComparison http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Version_Tag There are some very ugly was to work around insane versioning schemes, but we don't have that problem (and shouldn't get into hacky workarounds) -- Jesse Becker -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] releasing 3.3.2 today?
On 20/03/2012 17:57, Jesse Becker wrote: On Tue, Mar 20, 2012 at 13:36, Daniel Pocockdan...@pocock.com.au wrote: On 20/03/2012 17:34, Bernard Li wrote: On Tue, Mar 20, 2012 at 10:03 AM, Daniel Pocockdan...@pocock.com.au wrote: I agree with that approach, with a slight variation - I'll tag it as 3.3.3dp1 (after adding the ChangeLog file) Quick question -- does this prevent RPM upgrading? i.e. 3.3.3dp1 - 3.3.3? It is just a tag to help us keep track of what we test, it is not intended for versioning a binary package However, if we want to be able to version binary packages using release candidates, we may need to look at the problem more closely It matters very much for RPM packages, and I suspect debian packages as well (although I don't know the details of building those). RPMs inherently understand version numbers, and that 3.3.2 is a more recent release than 3.3.1. There are some further syntactic bits added in, such as package release numbers (which are essentially, the least significant digit in the version), but the version number matters a great deal. I think that versions such as 3.3.3pre1, 3.3.3pre2 and 3.3.3 are handled correctly. These pages details the issue: http://fedoraproject.org/wiki/Tools/RPM/VersionComparison According to that document, any suffix will make a version appear to be newer than the version without a suffix E.g., if RPM sees both 3.3.3pre1 and 3.3.3, it will believe 3.3.3pre1 is newer Therefore, we would need to have some suffix that we use for the final release too Before deciding on that though, it would be really useful to understand: a) just how much testing do people want to make with release candidates? Are people building RPMs and putting them in yum catalogues, etc, and expecting that to work? b) or is it just sufficient to build a package that can be manually installed (without yum) on a single box as a sanity check? c) and how do we find a common solution for all other platforms (Debian, OpenCSW, etc)? -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] releasing 3.3.2 today?
I don't really want to make a big deal out of this but I thought it was long agreed that we would tag a release (eg. 3.3.2) and that would potentially be our Release Candidate. If everything is fine, we will just release as is otherwise we will discard 3.3.2, bump the version to 3.3.3 and repeat the cycle. This way, there is a natural way to do upgrades via RPM but the downside is that we might artificially bump up our version numbers by quite a bit for official releases. Anyways, this is just my $0.02. Cheers, Bernard On Tue, Mar 20, 2012 at 11:00 AM, Daniel Pocock dan...@pocock.com.au wrote: On 20/03/2012 17:57, Jesse Becker wrote: On Tue, Mar 20, 2012 at 13:36, Daniel Pocockdan...@pocock.com.au wrote: On 20/03/2012 17:34, Bernard Li wrote: On Tue, Mar 20, 2012 at 10:03 AM, Daniel Pocockdan...@pocock.com.au wrote: I agree with that approach, with a slight variation - I'll tag it as 3.3.3dp1 (after adding the ChangeLog file) Quick question -- does this prevent RPM upgrading? i.e. 3.3.3dp1 - 3.3.3? It is just a tag to help us keep track of what we test, it is not intended for versioning a binary package However, if we want to be able to version binary packages using release candidates, we may need to look at the problem more closely It matters very much for RPM packages, and I suspect debian packages as well (although I don't know the details of building those). RPMs inherently understand version numbers, and that 3.3.2 is a more recent release than 3.3.1. There are some further syntactic bits added in, such as package release numbers (which are essentially, the least significant digit in the version), but the version number matters a great deal. I think that versions such as 3.3.3pre1, 3.3.3pre2 and 3.3.3 are handled correctly. These pages details the issue: http://fedoraproject.org/wiki/Tools/RPM/VersionComparison According to that document, any suffix will make a version appear to be newer than the version without a suffix E.g., if RPM sees both 3.3.3pre1 and 3.3.3, it will believe 3.3.3pre1 is newer Therefore, we would need to have some suffix that we use for the final release too Before deciding on that though, it would be really useful to understand: a) just how much testing do people want to make with release candidates? Are people building RPMs and putting them in yum catalogues, etc, and expecting that to work? b) or is it just sufficient to build a package that can be manually installed (without yum) on a single box as a sanity check? c) and how do we find a common solution for all other platforms (Debian, OpenCSW, etc)? -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] releasing 3.3.2 today?
On 20/03/12 19:27, Bernard Li wrote: I don't really want to make a big deal out of this but I thought it was long agreed that we would tag a release (eg. 3.3.2) and that would potentially be our Release Candidate. If everything is fine, we will just release as is otherwise we will discard 3.3.2, bump the version to 3.3.3 and repeat the cycle. I remember that discussion too, and I think was pushing that same argument - that it is easier to burn release numbers than to worry about suffixes That discussion was held in the days of SVN, when making a tag was quite painful Now we have git, - people can make local tags (almost like bookmarks?) whenever they like - you can make two tags on a single commit, because tags are like symlinks (e.g. 3.3.3rc1 and 3.3.3 both point to the same commit) This comes back to my earlier comments: the tags I have made today (e.g. 3.3.3dp1) are not intended for packaging, it is just a helpful reminder for me to know how I built the tarball for people to test. I think it is a useful phase in the release process. Once we get to the point where people want to test proper versioned RPMs, then we use a real tag (e.g. 3.3.3) and if the RPMs are proved to be dodgy after that tag is made, then we burn the version number and try 3.3.4 -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] releasing 3.3.2 today?
On Tue, Mar 20, 2012 at 14:52, Daniel Pocock dan...@pocock.com.au wrote: On 20/03/12 19:27, Bernard Li wrote: I don't really want to make a big deal out of this but I thought it was long agreed that we would tag a release (eg. 3.3.2) and that would potentially be our Release Candidate. If everything is fine, we will just release as is otherwise we will discard 3.3.2, bump the version to 3.3.3 and repeat the cycle. I remember that discussion too, and I think was pushing that same argument - that it is easier to burn release numbers than to worry about suffixes I agree. So long as the numbers only increase, the minor release number is basically irrelevant. That discussion was held in the days of SVN, when making a tag was quite painful Now we have git, - people can make local tags (almost like bookmarks?) whenever they like - you can make two tags on a single commit, because tags are like symlinks (e.g. 3.3.3rc1 and 3.3.3 both point to the same commit) This comes back to my earlier comments: the tags I have made today (e.g. 3.3.3dp1) are not intended for packaging, it is just a helpful reminder for me to know how I built the tarball for people to test. I think it is a useful phase in the release process. Once we get to the point where people want to test proper versioned RPMs, then we use a real tag (e.g. 3.3.3) and if the RPMs are proved to be dodgy after that tag is made, then we burn the version number and try 3.3.4 Now, with RPM releases, it may not be that bad. RPMs inherently support a release (in the RPM lingo), which is the least significant digit in the complete version number. If we have a ganglia release of X.Y.Z, the RPM release could go through several changes with it's own release number. The first RPM-release for a new upstream is 1, and each change increments. So the first official binary release would be something like X.Y.Z.-1, then -2, -3, etc. When Ganglia X.Y.(Z+1) is released, the RPM starts over: X.Y.(Z+1)-1 (and not, say, X.Y.(Z+1)-4) If we do make a policy of tagging pre-releases for testing, i suggest that the tag include something obvious, such as a pre1 sort of suffix. -- Jesse Becker -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] releasing 3.3.2 today?
On 20/03/12 19:59, Jesse Becker wrote: On Tue, Mar 20, 2012 at 14:52, Daniel Pocock dan...@pocock.com.au wrote: On 20/03/12 19:27, Bernard Li wrote: I don't really want to make a big deal out of this but I thought it was long agreed that we would tag a release (eg. 3.3.2) and that would potentially be our Release Candidate. If everything is fine, we will just release as is otherwise we will discard 3.3.2, bump the version to 3.3.3 and repeat the cycle. I remember that discussion too, and I think was pushing that same argument - that it is easier to burn release numbers than to worry about suffixes I agree. So long as the numbers only increase, the minor release number is basically irrelevant. That discussion was held in the days of SVN, when making a tag was quite painful Now we have git, - people can make local tags (almost like bookmarks?) whenever they like - you can make two tags on a single commit, because tags are like symlinks (e.g. 3.3.3rc1 and 3.3.3 both point to the same commit) This comes back to my earlier comments: the tags I have made today (e.g. 3.3.3dp1) are not intended for packaging, it is just a helpful reminder for me to know how I built the tarball for people to test. I think it is a useful phase in the release process. Once we get to the point where people want to test proper versioned RPMs, then we use a real tag (e.g. 3.3.3) and if the RPMs are proved to be dodgy after that tag is made, then we burn the version number and try 3.3.4 Now, with RPM releases, it may not be that bad. RPMs inherently support a release (in the RPM lingo), which is the least significant digit in the complete version number. If we have a ganglia release of What is the intention of that release number though? Is that intended to be maintained by upstream? Or is it reserved for the packager? If the Ganglia community releases a tarball called, 3.3.3-2.tar.gz, for example, then someone building RPM packages might release 3.3.3-2-1 The next day, the packager decides to modify a file location within his spec file. He is still using the same upstream tarball. He bumps his release number to 2, so it is 3.3.3-2-2.rpm In this case, the release number is used to distinguish different versions of a spec file maintained outside Ganglia. The same type of thing happens with Debian - the Debian maintainers keep their own artefacts in a repository, and they add a suffix to create the version numbers of their packages. One other comment: when I did the MSI packages (with WiX), I discovered the nasty world of Windows packaging, where you can only have a 4 byte version number, basically like an IP address, written as A.B.C.D where each value is between 0-255. Does anyone still build MSI packages? -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] releasing 3.3.2 today?
On Tue, Mar 20, 2012 at 15:08, Daniel Pocock dan...@pocock.com.au wrote:
On 20/03/12 19:59, Jesse Becker wrote:
On Tue, Mar 20, 2012 at 14:52, Daniel Pocock dan...@pocock.com.au wrote:
On 20/03/12 19:27, Bernard Li wrote:
I don't really want to make a big deal out of this but I thought it
was long agreed that we would tag a release (eg. 3.3.2) and that would
potentially be our Release Candidate. If everything is fine, we
will just release as is otherwise we will discard 3.3.2, bump the
version to 3.3.3 and repeat the cycle.
I remember that discussion too, and I think was pushing that same
argument - that it is easier to burn release numbers than to worry about
suffixes
I agree. So long as the numbers only increase, the minor release
number is basically irrelevant.
That discussion was held in the days of SVN, when making a tag was quite
painful
Now we have git,
- people can make local tags (almost like bookmarks?) whenever they like
- you can make two tags on a single commit, because tags are like
symlinks (e.g. 3.3.3rc1 and 3.3.3 both point to the same commit)
This comes back to my earlier comments: the tags I have made today (e.g.
3.3.3dp1) are not intended for packaging, it is just a helpful reminder
for me to know how I built the tarball for people to test. I think it
is a useful phase in the release process.
Once we get to the point where people want to test proper versioned
RPMs, then we use a real tag (e.g. 3.3.3) and if the RPMs are proved to
be dodgy after that tag is made, then we burn the version number and try
3.3.4
Now, with RPM releases, it may not be that bad. RPMs inherently
support a release (in the RPM lingo), which is the least significant
digit in the complete version number. If we have a ganglia release of
What is the intention of that release number though?
Yeah, the nomenclature gets confusing here. :-)
Is that intended to be maintained by upstream?
Or is it reserved for the packager?
The RPM version tag is maintained by upstream. Only in rare cases
should an outside packager assign a version number. And when they
do, IMO, it should be strictly date based--such as 20120320--instead
of an arbitrary version 1.0.
The RPM release, on the other hand, is strictly the purvue of the
packager, and indicates changes to the package that is distributed.
This can included updated metadata for the package, a fix to the build
or install process used in creating the package, fixing permissions,
or even adding code patches to the pristine upstream source code. All
of those are legitimate.
If the Ganglia community releases a tarball called, 3.3.3-2.tar.gz, for
example, then someone building RPM packages might release 3.3.3-2-1
If the Ganglia project really did release 3.3.3-2.tar.gz, we should
have our heads examined. :)
But yes, the resulting RPM could potentiall appear as you described,
and it would be a mess.
The next day, the packager decides to modify a file location within his
spec file. He is still using the same upstream tarball. He bumps his
release number to 2, so it is 3.3.3-2-2.rpm
Yep.
In this case, the release number is used to distinguish different
versions of a spec file maintained outside Ganglia.
That's exactly right.
The same type of thing happens with Debian - the Debian maintainers keep
their own artefacts in a repository, and they add a suffix to create the
version numbers of their packages.
We maintain an RPM repository at $day_job of program that come from
various researchers--many of whom wouldn't know proper software
engineering processes if they were hit over the head with a printed
copy of the of the CMM. Suffice it to say that we have a lot of
interesting version and number schemes to deal with. :-/
One other comment: when I did the MSI packages (with WiX), I discovered
the nasty world of Windows packaging, where you can only have a 4 byte
version number, basically like an IP address, written as A.B.C.D where
each value is between 0-255. Does anyone still build MSI packages?
Does anyone care? :)
The most complicated, non-contrived version/releases I've see are in
the kernel RPM packages. Here are some examples from a production
Centos 5 host. First, the full package is shown, including the name,
version, release and arch of the package:
$ rpm -q kernel
kernel-2.6.18-194.32.1.el5.centos.plus.x86_64
kernel-2.6.18-238.9.1.el5.centos.plus.x86_64
Now, just showing the version and release:
$ rpm -q --qf %{version} %{release}\n kernel
2.6.18 194.32.1.el5.centos.plus
2.6.18 238.9.1.el5.centos.plus
This works correctly because of the leading numbers in the release
tag--even though there is a bunch of extra non-numeric content as
well.
--
Jesse Becker
--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
Re: [Ganglia-developers] re-bootstrapping Ganglia
On 03/20/2012 06:19 PM, Daniel Pocock wrote: b) should Michael (or anyone else) need to modify Makefile.am from a tarball? If there are regular changes to Makefile.am after releases are made, shouldn't we find a way to incorporate such changes into trunk, or provide more variables for people to set things at build time? Let me explain my motivation to make changes to Makefile.am: I am maintaining for AIX and Linux on Power a couple of additional gmond DSO modules written in C. As those are probably only useful for people running AIX (or Linux on Power) I don't see a generic way to incorporate such changes into trunk. In order to compile and package the gmond module I intentionally keep the release tar.gz unchanged, i.e., any module is represented by a large source code patch against the respective release tar.gz. This is also the RPM-way of doing things (i.e., keep the vanilla source unchanged and anything else should be provided as a source code patch). So the patch for example for a metric called mod_netif adds or changes the following files/directories: ./gmond/modules/conf.d/netif.conf ./gmond/modules/netif/mod_netif-linux.c ./gmond/modules/netif/Makefile.am ./gmond/modules/Makefile.am ./gmond/Makefile.am ./configure.in Now one needs to run autoreconf -fi to incorporate the applied patches and that the respective Makefile.in files are generated from the patched Makefile.am files. I also keep separate SPEC files for all modules and have thus a clean separation of the original Ganglia release tar.gz files and my modules. In addition I can change the RPM release number independently of the core ganglia RPM release number which provides further flexibility. Regards, Michael -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] releasing 3.3.2 today?
On 03/20/2012 08:23 PM, Jesse Becker wrote:
If the Ganglia community releases a tarball called, 3.3.3-2.tar.gz, for
example, then someone building RPM packages might release 3.3.3-2-1
If the Ganglia project really did release 3.3.3-2.tar.gz, we should
have our heads examined. :)
But yes, the resulting RPM could potentiall appear as you described,
and it would be a mess.
Yes absolutely. Judging from my own experience having built thousands of
RPMs every time any release number that incorporates non-numbers just
leads to more or less confusion. Thus for a released tarball I would
definitely stay away from non-numbers and just stick with something like
X.Y.Z (X,Y,Z in [0..9]*). And just let the package maintainers (Debian,
RHEL etc.) maintain the X.Y.Z-R release number (R) for their package.
The most complicated, non-contrived version/releases I've see are in
the kernel RPM packages. Here are some examples from a production
Centos 5 host. First, the full package is shown, including the name,
version, release and arch of the package:
$ rpm -q kernel
kernel-2.6.18-194.32.1.el5.centos.plus.x86_64
kernel-2.6.18-238.9.1.el5.centos.plus.x86_64
Now, just showing the version and release:
$ rpm -q --qf %{version} %{release}\n kernel
2.6.18 194.32.1.el5.centos.plus
2.6.18 238.9.1.el5.centos.plus
This works correctly because of the leading numbers in the release
tag--even though there is a bunch of extra non-numeric content as
well.
That is because you really can't put any distro-specific version schemes
in the RPM %{version} number but in %{release}. That's why RHEL,
Mandrake etc. define a %{dist} that is typically added to %{release}.
And thankfully we have not run into %{epoch} here which makes things
even more complicated. :-)
Regards,
Michael
--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
___
Ganglia-developers mailing list
Ganglia-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] re-bootstrapping Ganglia
On 20/03/12 22:20, Michael Perzl wrote: On 03/20/2012 06:19 PM, Daniel Pocock wrote: b) should Michael (or anyone else) need to modify Makefile.am from a tarball? If there are regular changes to Makefile.am after releases are made, shouldn't we find a way to incorporate such changes into trunk, or provide more variables for people to set things at build time? Let me explain my motivation to make changes to Makefile.am: I am maintaining for AIX and Linux on Power a couple of additional gmond DSO modules written in C. As those are probably only useful for people Could you do this with ganglia-modules-linux instead? I'd be happy to apply such patches there if they are good for all Linux systems (or if they don't break it for non-Power builds) You could easily clone ganglia-modules-linux to make ganglia-modules-aix too In fact, the autotools stuff for ganglia-modules-linux was copied from ganglia-modules-solaris: http://gmod-linux.sourceforge.net/ http://gmod-solaris.sourceforge.net/ running AIX (or Linux on Power) I don't see a generic way to incorporate such changes into trunk. In order to compile and package the gmond module I intentionally keep the release tar.gz unchanged, i.e., any module is represented by a large source code patch against the respective release tar.gz. This is also the RPM-way of doing things (i.e., keep the vanilla source unchanged and anything else should be provided as a source code patch). I agree that RPM (and Debian) supports this, but when it touches Makefile.am, it is not exactly the autotools way of doing things. So the patch for example for a metric called mod_netif adds or changes the following files/directories: ./gmond/modules/conf.d/netif.conf ./gmond/modules/netif/mod_netif-linux.c ./gmond/modules/netif/Makefile.am ./gmond/modules/Makefile.am ./gmond/Makefile.am ./configure.in Now one needs to run autoreconf -fi to incorporate the applied patches and that the respective Makefile.in files are generated from the patched Makefile.am files. That is actually a really bad idea: because the Ganglia community can only really support one version of autotools at any time (the version used for official release bootstrapping), and bootstrapping again with a different version is likely to give you results that are `unique' to your project. As I mentioned, I'm not insisting that Debian 6.0 (squeeze) is the best platform for bootstrapping, but it is the platform that has been used since it was last discussed in 2009. Using autotools from any other platform is a risk (or at the very least, it creates extra work for you) I also keep separate SPEC files for all modules and have thus a clean separation of the original Ganglia release tar.gz files and my modules. In addition I can change the RPM release number independently of the core ganglia RPM release number which provides further flexibility. The spec files could go into ganglia-modules-linux if you think that is practical, but there is no obligation to work that way. -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
