Re: [Ganglia-developers] 3.3.4 tag doesn't build debian packages
On Tue, Apr 03, 2012 at 12:16:42PM -0700, Dave Rawks wrote: Am I missing something? I just downloaded the tarball tagged 3.3.4 from github and attempted to build debian packages from it. 1. The debian changelog is not updated to reflect the version tag. 2. the build dependencies appear to be broken, as the build requires libtools to be installed but that isn't called out in the control file. 3. the build fails when it attempts to descend into the web subdirectory of the build tree. I've been away from this project for a few weeks now and I was under the impression for the traffic on this list that some of the version tagging/workflow questions have been heavily discussed. However it seems that the actual function of the source tree may have become slowly and subtly broken at some point in the recent past (circa 3.2~) At any rate I've not got a lot of time on my hands to fix this at the moment, but figured I'd at least say something in case that might rouse some interest in fixing it. There are 3.3.5 packages available in debian experimental now, and I'll be pushing to sid as soon as I've rolled in some bugfixes and debconf translations. Stu -- From the prompt of Stu Teasdale While my BRAINPAN is being refused service in BURGER KING, Jesuit priests are DATING CAREER DIPLOMATS!! -- 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] 3.3.4 tag doesn't build debian packages
On 04/04/12 10:09, Stu Teasdale wrote: On Tue, Apr 03, 2012 at 12:16:42PM -0700, Dave Rawks wrote: Am I missing something? I just downloaded the tarball tagged 3.3.4 from github and attempted to build debian packages from it. 1. The debian changelog is not updated to reflect the version tag. 2. the build dependencies appear to be broken, as the build requires libtools to be installed but that isn't called out in the control file. 3. the build fails when it attempts to descend into the web subdirectory of the build tree. I've been away from this project for a few weeks now and I was under the impression for the traffic on this list that some of the version tagging/workflow questions have been heavily discussed. However it seems that the actual function of the source tree may have become slowly and subtly broken at some point in the recent past (circa 3.2~) At any rate I've not got a lot of time on my hands to fix this at the moment, but figured I'd at least say something in case that might rouse some interest in fixing it. There are 3.3.5 packages available in debian experimental now, and I'll be pushing to sid as soon as I've rolled in some bugfixes and debconf translations. Just to clarify: are there any bug fixes you had to apply on 3.3.5 that were never required on 3.3.1? In other words, there are no regressions between 3.3.1 and 3.3.5? -- 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] 3.3.4 tag doesn't build debian packages
On Wed, Apr 04, 2012 at 04:59:05PM +0200, Daniel Pocock wrote: Just to clarify: are there any bug fixes you had to apply on 3.3.5 that were never required on 3.3.1? In other words, there are no regressions between 3.3.1 and 3.3.5? All the fixes are to the packaging itself, rather than ganglia, and are present in the current debian unstable release. Stu -- From the prompt of Stu Teasdale There is a Massachusetts law requiring all dogs to have their hind legs tied during the month of April. -- 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
[Ganglia-developers] 3.3.4 tag doesn't build debian packages
Hi Stu: I am not too familiar with Debian and Ubuntu packaging but I just wanted make sure you and Jeff are aware of each other's work. Obviously we do not want any duplicated efforts. :) Going forward do you guys have any recommendations on how we can improve the Debian packaging files within our repository such that anybody downloading our official tarballs could build Debian packages out of it? Many thanks! Bernard On Wednesday, April 4, 2012, Stu Teasdale wrote: On Wed, Apr 04, 2012 at 04:59:05PM +0200, Daniel Pocock wrote: Just to clarify: are there any bug fixes you had to apply on 3.3.5 that were never required on 3.3.1? In other words, there are no regressions between 3.3.1 and 3.3.5? All the fixes are to the packaging itself, rather than ganglia, and are present in the current debian unstable release. Stu -- From the prompt of Stu Teasdale There is a Massachusetts law requiring all dogs to have their hind legs tied during the month of April. -- 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 -- 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 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] 3.3.4 tag doesn't build debian packages
On 04/04/12 17:58, Bernard Li wrote: Hi Stu: I am not too familiar with Debian and Ubuntu packaging but I just wanted make sure you and Jeff are aware of each other's work. Obviously we do not want any duplicated efforts. :) Going forward do you guys have any recommendations on how we can improve the Debian packaging files within our repository such that anybody downloading our official tarballs could build Debian packages out of it? I've actually queried this on the Debian mentors list (on behalf of a number of projects I work with) - you can find some good responses to that question in their list archives for March, in particular: http://wiki.debian.org/UpstreamGuide Summing up the feedback: our primary focus (wearing the Ganglia hat) should be to produce a tarball that is as neutral as possible for all packaging systems. E.g. rather than trying to set CFLAGS stuff within configure, we should leave CFLAGS entirely in the hands of the packager. Second to that, it appears that Debian recommends - NOT keeping a `debian' directory (similar to an RPM spec file) in our `trunk' or `master' branch - NOT distributing such a directory in our tarball The pattern in the Debian world involves keeping a Debian branch, and only that branch has the debian/ directory. In many cases, the Debian branch is not even in the upstream repository: it is in a separate repository (e.g. on the Debian server alioth) -- 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
Re: [Ganglia-developers] 3.3.4 tag doesn't build debian packages
On Wed, Apr 04, 2012 at 07:00:46PM +0200, Daniel Pocock wrote: I've actually queried this on the Debian mentors list (on behalf of a number of projects I work with) - you can find some good responses to that question in their list archives for March, in particular: http://wiki.debian.org/UpstreamGuide Summing up the feedback: our primary focus (wearing the Ganglia hat) should be to produce a tarball that is as neutral as possible for all packaging systems. E.g. rather than trying to set CFLAGS stuff within configure, we should leave CFLAGS entirely in the hands of the packager. Second to that, it appears that Debian recommends - NOT keeping a `debian' directory (similar to an RPM spec file) in our `trunk' or `master' branch - NOT distributing such a directory in our tarball The pattern in the Debian world involves keeping a Debian branch, and only that branch has the debian/ directory. In many cases, the Debian branch is not even in the upstream repository: it is in a separate repository (e.g. on the Debian server alioth) Indeed, the other key thing is that the repo on alioth only ever gets 'release' versions of ganglia imported into it, to hopefully avoid any bootstrap issues. I've been rather bad recently with my maintaining of the debian package, but hopefully I'm going to be able to keep it more p to date, especially with Daniel's help. 3.3.5-1 is now available in experimental, and I could potentially make backports of it to squeeze available if there's interest, otherwise the source packages should build fairly cleanly on squeeze and perhaps even lenny. Stu -- From the prompt of Stu Teasdale Even if you can deceive people about a product through misleading statements, sooner or later the product will speak for itself. -- Hajime Karatsu -- 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
[Ganglia-developers] pull requests
I can see a few outstanding pull requests for monitor-core git The 3.3 releases are built from the branch release/3.3 Therefore, people who have access are welcome to push their code direct to master, even in the middle of a release cycle, as it won't disturb the release branch. Once the changes are on master, it is very easy for the release manager to cherry pick them into the release/3.3 branch at a quiet time (between release candidates) -- 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
[Ganglia-developers] 3.3.5 released today
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Release 3.3.5 is now official and ready for distribution The release was is tagged in git commit = 9db9beea062c7ce5e5b4d10ed553c9b7cea7642e Filename: ganglia-3.3.5.tar.gz SHA256 checksum: 8934ca140cdeef1f3216d8276e18c7f9be5724ca80335fc9bc8b7e2abe55af34 https://sourceforge.net/projects/ganglia/files/ A number of bugs were found during the testing of 3.3.5 and discussed on the mailing lists. However, we do not believe any of them is a new bug. In other words, anyone who is using 3.3.1 or 3.3.0 should not get any new bugs from upgrading to 3.3.5 Binary packages will shortly appear in the usual places (Debian unstable, OpenCSW unstable, etc) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJPfNCiAAoJEGxlgOd711bEtdcP/izWC7SnG4sAvP4ctYLOWJ4U Pyv9vtYjY+5STMmSag98fqJXrhYURofJZhdUvFx5974g10q/Wn0DbvT5PLxHLjgx b5aMlQs+jr3+P7rhWA+r/vJamQ2oK5JGweIy43f8jPg/iFT8ZD+aqxOCqcvrv9L5 aV2pMuH+GGqnHWxR4rkvR35/07Iy/ny+YznAI5otwPWu66yFzTToQsLs8Pe8t8g5 +1H7sZAYRseJ5mKB8Hn7+Zl/WX6wOvmh/a9A4Ob/cgkum5Cep+VOvvbctdr7KfH2 cjSNeOBxCMFNjbKn4hU+nbX1WW/+CvXE9EworFdZ01V1y08XT8MzkXXWz9/x3b2W ckrgqu+kXzFDUfGXnEBxsMLDGmD2raQULpMFY0WvneV2Ib7+8243+qdISOhqyWcQ y1gQajt5cJKeeRaImduflXqYhGmx/FgfDRnY4WEbCHtzuV3rgCbQUnd679dm0Oab 29nLEbc/uhtGGBeIZZWLklSXSIou47bVFMqkgBXT3sfm5nKoKhkTUFLi25rNnGff guCCOVC0dpb4lr31en+/xX5k9qsQDmiAIzTbawyj0L7YlgYFI3EQ9gyv9sqZY6Ry dh0YhsMsly5TZhMyCVv6hRCfwH6sY0CZkJhey9Cm2V2ZUILcR7umxiC/edcQ+0pb QRYI8AES+LQxS2BDl5Zl =9eTJ -END PGP SIGNATURE- -- 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
