Re: [Ganglia-developers] bootstrap / autotools (renamed)
On 04/04/12 18:35, Dave Rawks wrote: Not to speak out of turn, but making the build process dependent on a very specific version of libtools and autotools seems like a really bad plan. I've never run into a debian source package before that demands to Only the `bootstrap' step recommends a particular version of autotools. There would be more QA risk if every revision (e.g. 3.3.5, 3.3.6, 3.3.7) was bootstrapped on a different autotools. Given the limited resources of the project, the easiest way to ensure consistency between releases is to make sure that we always bootstrap on a specified platform before making a release tarball. This only impacts people who want to work with source code directly from git (rather than using a tarball) be built only with specific versions from Debian current stable (squeeze) especially when the goal of the maintainers appears to be inclusion into testing/new-stable. Personally I would like for the entire tarball to have a nice sensible autotools based build install process ./configure make make install that can be quickly packaged up with a super minimal amount of distro specific munging. It does do that: someone who downloads the tarball should NOT run the bootstrap script (and should not have to run it). -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] bootstrap / autotools (renamed)
On 04/04/2012 09:51 AM, Daniel Pocock wrote: On 04/04/12 18:35, Dave Rawks wrote: Not to speak out of turn, but making the build process dependent on a very specific version of libtools and autotools seems like a really bad plan. I've never run into a debian source package before that demands to Only the `bootstrap' step recommends a particular version of autotools. There would be more QA risk if every revision (e.g. 3.3.5, 3.3.6, 3.3.7) was bootstrapped on a different autotools. Given the limited resources of the project, the easiest way to ensure consistency between releases is to make sure that we always bootstrap on a specified platform before making a release tarball. This only impacts people who want to work with source code directly from git (rather than using a tarball) Well, if you've ever tried to build the debian source package, in the middle of whatever is called from debian/rules build there is echo'd a stern warning about autotools versions and it looks like a few git commands are attempted but fail without stopping the build. -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] bootstrap / autotools (renamed)
On Wed, Apr 04, 2012 at 06:51:27PM +0200, Daniel Pocock wrote: On 04/04/12 18:35, Dave Rawks wrote: be built only with specific versions from Debian current stable (squeeze) especially when the goal of the maintainers appears to be inclusion into testing/new-stable. Personally I would like for the entire tarball to have a nice sensible autotools based build install process ./configure make make install that can be quickly packaged up with a super minimal amount of distro specific munging. It does do that: someone who downloads the tarball should NOT run the bootstrap script (and should not have to run it). and that is why until recently wasn't included in the tarball, so no one would get confused. Carlo -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] bootstrap / autotools (renamed)
On 04/04/12 19:30, Dave Rawks wrote: On 04/04/2012 09:51 AM, Daniel Pocock wrote: On 04/04/12 18:35, Dave Rawks wrote: Not to speak out of turn, but making the build process dependent on a very specific version of libtools and autotools seems like a really bad plan. I've never run into a debian source package before that demands to Only the `bootstrap' step recommends a particular version of autotools. There would be more QA risk if every revision (e.g. 3.3.5, 3.3.6, 3.3.7) was bootstrapped on a different autotools. Given the limited resources of the project, the easiest way to ensure consistency between releases is to make sure that we always bootstrap on a specified platform before making a release tarball. This only impacts people who want to work with source code directly from git (rather than using a tarball) Well, if you've ever tried to build the debian source package, in the middle of whatever is called from debian/rules build there is echo'd a stern warning about autotools versions and it looks like a few git commands are attempted but fail without stopping the build. This may not be the official process for building a Debian package The official process is being documented at the moment, various packaging things like that are covered here already (Debian coming soon): https://github.com/ganglia/monitor-core/wiki/ReleaseTesting If the debian/rules file you are using calls git commands, that is also a sign of trouble, Debian policy prohibits any dependency on the network during the build process -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] bootstrap / autotools (renamed)
On 04/04/12 19:31, Carlo Marcelo Arenas Belon wrote:
On Wed, Apr 04, 2012 at 06:51:27PM +0200, Daniel Pocock wrote:
On 04/04/12 18:35, Dave Rawks wrote:
be built only with specific versions from Debian current stable
(squeeze) especially when the goal of the maintainers appears to be
inclusion into testing/new-stable. Personally I would like for the
entire tarball to have a nice sensible autotools based build install
process ./configure make make install that can be quickly
packaged up with a super minimal amount of distro specific munging.
It does do that: someone who downloads the tarball should NOT run the
bootstrap script (and should not have to run it).
and that is why until recently wasn't included in the tarball, so no one
would get confused.
I accept full responsibility for adding that to the tarball, and I've
made sure it is not there for 3.3.6 and beyond
see commit: 8c3de40
However, this came about when I surveyed all the files that were not in
the tarball, and went about updating the EXTRA_DIST variables in the
Makefile.am files - this hasn't been done for quite some time, many
things were not in the tarball, it's quite possible that I've added
other things that should not be distributed too, so please feel free to
point them out
This finds the relevant lines, but doesn't follow lines that are
continued by a backslash:
$ find . -name Makefile.am -exec grep -H DIST '{}' \;
./gmetric/Makefile.am:EXTRA_DIST = cmdline.sh
./libmetrics/Makefile.am:DIST_SUBDIRS = aix cygwin darwin dragonfly
freebsd hpux irix linux mingw netbsd openbsd osf solaris tests
./libmetrics/Makefile.am:EXTRA_DIST = bootstrap
./Makefile.am:GANGLIA_SUBDIRS_DIST = lib libmetrics tests gmetad gmond
gstat gmetric include mans
./Makefile.am:DIST_SUBDIRS = $(GANGLIA_SUBDIRS_DIST)
./Makefile.am:EXTRA_DIST = BUGS README.WIN README.AIX README.GIT
ganglia.spec.aix ganglia.spec ganglia.pod ganglia.html ganglia-config.in \
./lib/Makefile.am:EXTRA_DIST=gm_protocol.x
./gstat/Makefile.am:EXTRA_DIST = cmdline.sh
./gmond/modules/python/Makefile.am:EXTRA_DIST = README.in
../conf.d/modpython.conf.in
./gmond/modules/Makefile.am:DIST_SUBDIRS = example cpu disk memory
network system status python
./gmond/modules/cpu/Makefile.am:EXTRA_DIST = ../conf.d/multicpu.conf
./gmond/modules/status/Makefile.am:EXTRA_DIST = ../conf.d/modgstatus.conf
./gmond/modules/example/Makefile.am:EXTRA_DIST = ../conf.d/example.conf
./gmond/Makefile.am:EXTRA_DIST = gmond.aix.init gmond.solaris.init.in
gmond.init gmond.init.SuSE gmond.conf.5 gmond.conf.html conf.pod cmdline.sh
./gmond/python_modules/vm_stats/Makefile.am:EXTRA_DIST = $(pys)
./gmond/python_modules/apache_status/Makefile.am:EXTRA_DIST = $(pys)
./gmond/python_modules/memory/Makefile.am:EXTRA_DIST = $(pys)
./gmond/python_modules/nfs/Makefile.am:EXTRA_DIST = $(pys)
./gmond/python_modules/disk/Makefile.am:EXTRA_DIST = $(pys)
./gmond/python_modules/Makefile.am:DIST_SUBDIRS = apache_status db disk
example memcached memory network nfs process ssl varnish vm_stats xen
./gmond/python_modules/Makefile.am:EXTRA_DIST = ./conf.d/*.pyconf
./conf.d/*.pyconf.disabled
./gmond/python_modules/network/Makefile.am:EXTRA_DIST = $(pys)
README.traffic1.mkdn
./gmond/python_modules/process/Makefile.am:EXTRA_DIST = $(pys)
./gmond/python_modules/db/Makefile.am:EXTRA_DIST = $(pys)
./gmond/python_modules/example/Makefile.am:EXTRA_DIST = $(pys)
./gmond/python_modules/ssl/Makefile.am:EXTRA_DIST = $(pys)
./gmond/python_modules/memcached/Makefile.am:EXTRA_DIST = $(pys)
./gmond/python_modules/varnish/Makefile.am:EXTRA_DIST = $(pys)
./gmond/python_modules/xen/Makefile.am:EXTRA_DIST = $(pys)
./gmetad/Makefile.am:EXTRA_DIST = gmetad.aix.init gmetad.conf.in
gmetad.init gmetad.init.SuSE \
--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
___
Ganglia-developers mailing list
Ganglia-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
