Bug#535691: Bug #535691,RFH: munin -- help packaging 1.3 to experimental and report bugs upstream
Hi, On Sonntag, 27. September 2009, Tom Feiner wrote: I committed the non-debian specific changes to trunk, not through patches. I spoke to Nicolai, and he said that it's ok to fix these kind of trivial issues (such as http://munin.projects.linpro.no/changeset/2471) directly in trunk, and its even OK for not such trivial issues as he's looking at commits and will keep an eye to make sure everything is in order. Cool! (And as said: I assumed that, but just wanted to be sure :) I think this is the best way, as then we don't need so many patches on top of the orig.tar.gz, and the rest non-debian munin users will benefit from the fixes as well. Absolutly. OK, I'll leave /var/www/munin as is until we're sure of what we want to do about it. Yup, I see it at each upload and should probably just write this mail to debian-devel... doing so now :-) regards, Holger signature.asc Description: This is a digitally signed message part.
Bug#535691: Bug #535691,RFH: munin -- help packaging 1.3 to experimental and report bugs upstream
Hi, Holger Levsen wrote: Yup, I see it at each upload and should probably just write this mail to debian-devel... doing so now :-) I think the webapps policy outlines the right thing to do in this case, however it focuses on what needs to be done for new packages, and its not clear how the migration should be handled in upgrades, I guess that's where debian-devel can help. http://webapps-common.alioth.debian.org/draft/html/ Regards, Tom Feiner signature.asc Description: OpenPGP digital signature
Bug#535691: Bug #535691,RFH: munin -- help packaging 1.3 to experimental and report bugs upstream
Hi Tom, (it would be nice not to cc: me when mailing the BTS, I'm subscribed to the munin package :-) On Sonntag, 27. September 2009, Tom Feiner wrote: I think the webapps policy outlines the right thing to do in this case, however it focuses on what needs to be done for new packages, and its not clear how the migration should be handled in upgrades, I guess that's where debian-devel can help. http://webapps-common.alioth.debian.org/draft/html/ I dont see it in there. Can you help me please? Neither 3.1 nor 5.1.1 is helpful AFAICS... regards, Holger signature.asc Description: This is a digitally signed message part.
Bug#535691: Bug #535691,RFH: munin -- help packaging 1.3 to experimental and report bugs upstream
Holger Levsen wrote: Hi Tom, (it would be nice not to cc: me when mailing the BTS, I'm subscribed to the munin package :-) On Sonntag, 27. September 2009, Tom Feiner wrote: I think the webapps policy outlines the right thing to do in this case, however it focuses on what needs to be done for new packages, and its not clear how the migration should be handled in upgrades, I guess that's where debian-devel can help. http://webapps-common.alioth.debian.org/draft/html/ I dont see it in there. Can you help me please? Neither 3.1 nor 5.1.1 is helpful AFAICS... Well, 3.1 points to the correct location for the static/interpreted files, and also mentions where not to put content: From 3.1: Web applications should follow the same guidelines as any other software. Most specifically, they should not make any assumption about how the administrator has arranged the file hierarchy outside of the FHS by placing files in non-standard places such as /home, /srv, /var/www or /usr/local. Specifically, the following table should serve as a guideline for the placement of files: Static and dynamically interpreted content /usr/share/PACKAGE/www Dynamically executed content A unique subdirectory of either /usr/lib/cgi-bin/PACKAGE or /usr/lib/PACKAGE (architecture-dependant) or A unique subdirectory of /usr/share/PACKAGE (architecture-independant) This is exactly how other packages, like phpmyadmin work (they too needed to migrate from /var/www to /usr/share/PACKAGE/). So it looks like /usr/share/munin/www is the right place for the static stuff (logo, css, ext). Regarding the graphs generated by munin-graph, and placed in /var/www/munin (today), I agree there's no indication in the document on where to place these files, I guess that's where we need advice from debian-devel. Regards, Tom Feiner signature.asc Description: OpenPGP digital signature
Bug#535691: Bug #535691,RFH: munin -- help packaging 1.3 to experimental and report bugs upstream
Holger Levsen wrote: Nope, it's not: $ dpkg --compare-versions 1.4.0-dev+svn2484 lt 1.4.0-1 ; echo $? 1 $ dpkg --compare-versions 1.4.0-dev+svn2484 gt 1.4.0-1 ; echo $? 0 Please use 1.4.0~dev+svn2484, so that we can upload 1.4.0-1 if we want to :-) Hmm, 1.4.0~svn2481-1 is even better or 1.4.0~dev+svn2484-1... Thanks for noticing :), I've changed the name to 1.4.0~svn2481-1. Just to be clear: you committed to trunk or did you modify trunk by means of debian/patches/ ? I committed the non-debian specific changes to trunk, not through patches. I spoke to Nicolai, and he said that it's ok to fix these kind of trivial issues (such as http://munin.projects.linpro.no/changeset/2471) directly in trunk, and its even OK for not such trivial issues as he's looking at commits and will keep an eye to make sure everything is in order. I think this is the best way, as then we don't need so many patches on top of the orig.tar.gz, and the rest non-debian munin users will benefit from the fixes as well. IMO we should leave this (lintian warnings) as they are, as these are issues we/upstream need to fix. Changing the location from /var/www to /srv/www/munin or such is something I would really like to see fixed for squeeze, but I'm not really sure what is the best location. Maybe we should start a thread on debian-devel@ to gather information+opinions how other packages handle that. OK, I'll leave /var/www/munin as is until we're sure of what we want to do about it. W: munin: executable-not-elf-or-script ./usr/share/munin/VeraMono.ttf debian/rules should delete that file and we should use this font from the proper package already in Debian. I guess debian has the same VeraMono.ttf in the package: http://packages.debian.org/sid/ttf-dejavu (although the name is a bit different - DejaVuSansMono.ttf). I've opened bug http://bugs.debian.org/548508 for this issue. and committed a patch to fix this in experimental. Regards, Tom Feiner signature.asc Description: OpenPGP digital signature
Bug#535691: Bug #535691,RFH: munin -- help packaging 1.3 to experimental and report bugs upstream
Hi, OK, I cleaned up /branches/debian/experimental (I tagged the previous contents of this dir under /branches/debian/experimental/tags/1.3.3-1). I created the following structure under /branches/debian/experimental/: tags/ trunk/debian/ tarballs/ Following Stig's recommendation, I've used version 1.4.0-dev+svn2484 as the version name. I hope that's ok. Merged the latest trunk/debian from branches/debian/squeeze/trunk/debian, and added the following changes to at least make a rudimentary package: * debian/rule - make target names have changed. * Added suggests to ruby for munin-node. * Added depends to liblog-log4perl-perl for munin. * Updated new manpages names for munin-node.manpages. In upstream trunk: * Slightly modified upstream Makefile to honor overriding Makefile.config, as it does in 1.2.6, but didn't do in trunk. * Solved some lintian problem upstream (minor pod formatting issues which raised lintian warnings). This takes care of the changes need to build the packages, the resulting packages are almost lintian clean, the following warnings/errors remain for the munin package: W: munin: binary-without-manpage usr/bin/munin-check E: munin: dir-or-file-in-var-www var/www/munin/ E: munin: dir-or-file-in-var-www var/www/munin/.htaccess E: munin: dir-or-file-in-var-www var/www/munin/favicon.ico W: munin: executable-not-elf-or-script ./usr/share/munin/VeraMono.ttf The 2 warnings are easy to fix, however the dir-or-file-in-var-www is a bit more complicated, as 1.2.6 uses it too. I guess for experimental we can do the right thing which is to place the www section under /usr/share/munin/www and add an apache alias to point there. But I'm not sure how well this will behave in upgrades from 1.2.6. munin-node and munin-plugins extra are currently lintian clean. Open issues: * Currently the series file is empty, so no patches from 1.2.6 line are applied. There's still work to do, going over the patches one by one, checking if they have been merged upstream, if not, check if it's possible to merge them upstream, and if that's still not an option, apply them. * Lintian error: dir-or-file-in-var-www. * munin-update, munin-limits, munin-graph munin-html all fail to run because of minor perl syntax errors. Still need to check if this is a problem upstream or because of the packaging. munin-node works fine at this point. Please let me know if I should be doing anything differently, any help,advice,comments would be appreciated :) Regards, Tom Feiner signature.asc Description: OpenPGP digital signature
Bug#535691: Bug #535691,RFH: munin -- help packaging 1.3 to experimental and report bugs upstream
Hi, After looking at the patches, I was able to delete the following 29 patches, which were already included in upstream trunk: - 100-node.d-tomcat_access.patch - 110-node.d-tomcat_jvm.patch - 120-node.d-tomcat_threads.patch - 130-node.d-tomcat_volume.patch - 140-node.d-ups_.patch - 160-node.d-postgres-plugins.patch - 200-node-plugins.history.patch - 210-munindoc-manpage.patch - 211-munin-manpage.patch - 220-Makefile.patch - 231-exim_mailstats.patch - 232-ntp_offset.patch - 234-smart_.patch - 270-Plugin.pm-typo.patch - 310-node-configure_bugfix - 330-courier-typo - 340-nfsd-fix.patch - 350-munin-run-usage-fix.patch - 380-munin-graph-utf8.patch - 410-muninnodeconf-manpage.patch - 450-munin-cgi-graph.patch - 480-node.d-apache-asterisk.patch - 490-node.d-asterisk-if.in - 520-node.d-nut-plugins - 540-node.d-acpi-lenny - 571-node.d-postfix-mailstats.patch - 572-node.d-postfix-mailstats.patch - 600-munin-node-conf-setsid.patch - 610-plugin-cpu-fix-max.patch Goodbye low hanging fruit :) Now we are left with the real work. Regards, Tom Feiner signature.asc Description: OpenPGP digital signature
Bug#535691: Bug #535691,RFH: munin -- help packaging 1.3 to experimental and report bugs upstream
Hi Tom, On Freitag, 25. September 2009, Tom Feiner wrote: OK, I cleaned up /branches/debian/experimental (I tagged the previous contents of this dir under /branches/debian/experimental/tags/1.3.3-1). I've followed your commits, great! Following Stig's recommendation, I've used version 1.4.0-dev+svn2484 as the version name. I hope that's ok. Nope, it's not: $ dpkg --compare-versions 1.4.0-dev+svn2484 lt 1.4.0-1 ; echo $? 1 $ dpkg --compare-versions 1.4.0-dev+svn2484 gt 1.4.0-1 ; echo $? 0 Please use 1.4.0~dev+svn2484, so that we can upload 1.4.0-1 if we want to :-) Hmm, 1.4.0~svn2481-1 is even better or 1.4.0~dev+svn2484-1... In upstream trunk: Just to be clear: you committed to trunk or did you modify trunk by means of debian/patches/ ? * Slightly modified upstream Makefile to honor overriding This takes care of the changes need to build the packages, the resulting packages are almost lintian clean, the following warnings/errors remain for the munin package: W: munin: binary-without-manpage usr/bin/munin-check E: munin: dir-or-file-in-var-www var/www/munin/ E: munin: dir-or-file-in-var-www var/www/munin/.htaccess E: munin: dir-or-file-in-var-www var/www/munin/favicon.ico IMO we should leave this (lintian warnings) as they are, as these are issues we/upstream need to fix. Changing the location from /var/www to /srv/www/munin or such is something I would really like to see fixed for squeeze, but I'm not really sure what is the best location. Maybe we should start a thread on debian-devel@ to gather information+opinions how other packages handle that. W: munin: executable-not-elf-or-script ./usr/share/munin/VeraMono.ttf debian/rules should delete that file and we should use this font from the proper package already in Debian. The 2 warnings are easy to fix, hah. I should finish reading mails before starting to answer them ;-) however the dir-or-file-in-var-www is a bit more complicated, as 1.2.6 uses it too. I guess for experimental we can do the right thing which is to place the www section under /usr/share/munin/www and add an apache alias to point there. Hm, doesnt munin still store files there? /usr needs to be read-only :) But I'm not sure how well this will behave in upgrades from 1.2.6. As a first thought, I wouldn't change that on upgrades, but only for new installations. Then we just need to make sure it works for upgrades :) Please let me know if I should be doing anything differently, any help,advice,comments would be appreciated :) See above :-) I think you are doing great, thanks a lot! regards, Holger signature.asc Description: This is a digitally signed message part.
Bug#535691: ,RFH: munin -- help packaging 1.3 to experimental and report bugs upstream
Hi Tom, On Dienstag, 22. September 2009, Tom Feiner wrote: Was the patch prepared by Niels ever applied? From what I can see in svn it hasn't been applied yet. to be honest, I have no idea... :-/ Can we prepare the svn location for packaging munin 1.3? (I'm guessing it'll be /branches/debian/experimental, but there is currently code there to package 1.3.3. that branch is the right one, just remove the existing stuff there, if you think that's right! :-) Whats the best way to approach this? I guess now's the time to work on this, as we now have a time frame to get the uncommitted patches into trunk, thus reducing the number of patches we need to maintain. I fully agree. Thanks regards, Holger signature.asc Description: This is a digitally signed message part.
Bug#535691: ,RFH: munin -- help packaging 1.3 to experimental and report bugs upstream
Hi Holger, Was the patch prepared by Niels ever applied? From what I can see in svn it hasn't been applied yet. Can we prepare the svn location for packaging munin 1.3? (I'm guessing it'll be /branches/debian/experimental, but there is currently code there to package 1.3.3. Whats the best way to approach this? I guess now's the time to work on this, as we now have a time frame to get the uncommitted patches into trunk, thus reducing the number of patches we need to maintain. Thanks, Tom Feiner signature.asc Description: OpenPGP digital signature
Bug#535691: ,RFH: munin -- help packaging 1.3 to experimental and report bugs upstream
Tom Feiner feiner@gmail.com writes: Can we prepare the svn location for packaging munin 1.3? (I'm guessing it'll be /branches/debian/experimental, but there is currently code there to package 1.3.3. Whats the best way to approach this? I guess now's the time to work on this, as we now have a time frame to get the uncommitted patches into trunk, thus reducing the number of patches we need to maintain. It may make sense to package upstream trunk as 1.4~dev-something, I guess that's going to be far closer to 1.4 than what the 1.3 branch is for the moment. On the other hand, it may not work at all... -- Stig Sandbeck Mathisen Trust the Computer, the Computer is your Friend pgpAnD2SXrg4G.pgp Description: PGP signature