Bug#670428: [Packaging] Bug#670428: /usr/share/munin/plugins/spamstats: no license to redistribute plugin spamstats
Hi, - Original Message - On Mittwoch, 25. April 2012, Helmut Grohne wrote: On IRC Steve Schnepp (upstream) mentioned that the committer of spamstats was jimmyo. can you please comment on #670428?! Thanks already :-) Indeed, that one was done by me. That code is ancient enough to be from when the we weren't good enough at putting the license in each file, which is why it's been tagged as unknown by the people adding the pod doc. The license is GPLv2. -jo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670428: [Packaging] Bug#670428: /usr/share/munin/plugins/spamstats: no license to redistribute plugin spamstats
- Original Message - On Fri, Apr 27, 2012 at 12:59, Jimmy Olsen j...@redpill-linpro.com wrote: unknown by the people adding the pod doc. The license is GPLv2. Can we assume that all the code that seems attributed to you is GPLv2 ? Yes. When the Munin project was started by Audun Ytterdal and me, we discussed the license, and we both agreed that GPLv2 was the best license for it. Any code attributed to me is GPLv2 (unless it's modifications to an existing file with another license, of course.) -jo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#302502: munin-update unitialized variable
tags 302502 +fixed-upstream thanks, Once upon a time, Micah Anderson [EMAIL PROTECTED] sagely scribed: Every update, I kept getting the following message emailed to me: Use of uninitialized value in scalar chomp at /usr/share/munin/munin-update line 753. Fixed in svn. -jo (upstream) :-) pgpqYJz7fqMpi.pgp Description: PGP signature
Bug#302220: postfix_mailstats: overzealous regex for rejects
Hi Chad,
Once upon a time, Chad Walstrom [EMAIL PROTECTED] sagely scribed:
If you will note by the following log entries, postfix rejects messages
from different applications with different message formats. The first
listed is from the cleanup daemon rejecting a message based on
mime_header regex matching.
Mar 29 17:20:43 hostname postfix/cleanup[15643]: [...]
[...]
I propose the following change to line 232::
232 elsif ($line =~ /postfix\/smtpd.*reject: \S+ \S+ \S+ (\S+)/)
At a minimum I'll make this change.
In addition to that, what do you think about the additional elsif?
elsif ($line =~ /postfix\/cleanup.* reject:/)
{
$rejects-{cleaned} ++;
}
I'm asking since I don't use the postfix plugins myself, and therefore don't
know for sure what data is interesting and what is not.
-jo :-)
pgpi5OZWrRueY.pgp
Description: PGP signature
Bug#300690: munin-node: [plugin:sensors_] fails to extract the sensor name on multiline output
tags 300690 +fixed-upstream thanks, Once upon a time, Matthieu Lochegnies [EMAIL PROTECTED] sagely scribed: If I change the regexp so that the name cannot begin with spaces, the problem is fixed; I dont know if it can break other configs. I don't think it can. I've applied the patch upstream, to the 1.2 and 1.3 series. Thanks. -jo :-) pgpKke6CGAokI.pgp Description: PGP signature
Bug#301361: Move processing from apt_all plugin to apt-get update cronjob
tags 301361 +fixed-upstream thanks, Once upon a time, Andras Korn [EMAIL PROTECTED] sagely scribed: The processing done by the apt_all plugin can be rather expensive if there are many packages installed and/or many sources in sources.list. On one of my systems the plugin even times out sometimes. I've changed this in the upstream repository, but only in the 1.3 branch, not the 1.2 stable branch (too big a change). If the Debian packagers want to patch their version, the changes can be found between svn revisions 870:871. -jo (upstream) :-) pgpsfwvDdF2vo.pgp Description: PGP signature
Bug#296575: [fwd Re: Bug#296575: munin: Nested quantifiers in regex]
tags 296575 +fixed-upstream thanks, Once upon a time, Jean Charles Delepine [EMAIL PROTECTED] sagely scribed: Resent since I sent it firstly privately because of the size of the file but received no answer. Hmm...you sent it to me, or someone else? No matter, the problem should go away with the next version now -- it's been fixed in the 1.2 and 1.3 branches of CVS. Thanks for the report. -jo (upstream) :-) signature.asc Description: Digital signature
Bug#298442: munin-node: plugin df_inode doesn't convert - in device names
tags 298442 +fixed-upstream thanks, Once upon a time, Herbert Thielen [EMAIL PROTECTED] sagely scribed: The plugin /usr/share/munin/plugins/df_inode doesn't convert - characters in device names to _. Device names happen to have - if using logical volumes. These devices currently aren't displayed via df_inode. Now fixed in 1.2 and 1.3 CVS. The following patch resolves this, and also avoids logging of CDROM/DVD (iso9660 file systems) and tmpfs filesystems, which is of no interest (at least for me :-)). I added the exclude for iso9660, and a couple of others, but not tmpfs, since those are of interest to a lot of people. I did, however, make sure that all tmpfs systems were listed (earlier only one would be listed). Thanks for the report. -jo :-) signature.asc Description: Digital signature
Bug#295799: exim_mailstats does not show rejected email, unlike sendmail plugin
tags 295799 +fixed-upstream thanks, Patch applied (with some modifications). Thanks. :-) -jo (upstream) signature.asc Description: Digital signature
Bug#297904: munin-node: mailman plugin improperly uses domains
tags 297904 +fixed-upstream thanks, Once upon a time, Charles Fry [EMAIL PROTECTED] sagely scribed: The current mailman plugin improperly uses domains. Specifically, it assumes a mailman installation that is different from the current Debian mailman installation. I've modified the contribution plugin mailman to handle both regular mailman, as well as mailman modified for multi-domain use. -jo (upstream) :-) signature.asc Description: Digital signature
Bug#296436: munin: smart_* shows wrong temperature
tags 296436 +wontfix thanks, Once upon a time, Bastian Venthur [EMAIL PROTECTED] sagely scribed: The temperature-output of this plugin shows a value about 100degreeCelsius. I think the data needs to be evaluated, since the data is *not* the temp in celsius, than some raw-value. You're correct -- this is a raw value which, on some harddrives, is not the temp directly. The smart_* plugins use smartctl to fetch its data. Smartctl has some vendor-specific options to deal with this problem, e.g., on some Samsung drives you need to say: smartctl -a /dev/hda -v 194,10xCelsius I don't know what you have to add to your drive, but if you find the correct option, then add a file in /etc/munin/plugin-conf.d/ (call the file what you like), with the contents (just replace the params with your own): [smart_*] env.smartargs -v 194,10xCelsius ...you should start getting more proper temperature settings. -jo (upstream) :-) pgpRLeuVhQzIO.pgp Description: PGP signature
Bug#296645: Bug#296454: works now
tags 296454 +fixed-upstream tags 296645 +fixed-upstream thanks This problem (these tickets are the same problem) is now fixed in CVS (1.2 and 1.3 series). -jo :-) pgpOrcl7ZJS6U.pgp Description: PGP signature
Bug#297628: munin-node: courier_ plugin error
tags 297628 +fixed-upstream thanks, Once upon a time, Charles Fry [EMAIL PROTECTED] sagely scribed: The current courier_ plugin fails on my system. It yields the error: No logfile to read. Use -f switch. There was an error in the detection of which type of logtail argumets to use (there are several different logtail programs around). This has now been fixed in the 1.2 and 1.3 branches in CVS. Thanks for the report. -jo (upstream) :-) pgpSAslx2eEup.pgp Description: PGP signature
Bug#296533: munin-node: amavis plugin uses wrong log path, and cannot override it
bugs 296533 +fixed-upstream thanks, Once upon a time, Daniel Pittman [EMAIL PROTECTED] sagely scribed: The 'amavis' plugin supplied with munin looks in the wrong place for the mail log file, at least with the standard Debian syslog configuration. Worse, there isn't a simple way to override it from the munin configuration, like there are with many others. This simple patch makes it configurable, and should be suitable for sending upstream. I've applied the patch to CVS. The change will be in version 1.2.1. I won't change the default (as suggested by Juraj), as this is better done in the package file in plugin-conf.d, by the Debian maintainer. -jo (upstream fellow :-) signature.asc Description: Digital signature
Bug#296575: munin: Nested quantifiers in regex
tags 296575 +moreinfo thanks, Once upon a time, Jean Charles Delepine [EMAIL PROTECTED] sagely scribed: + nice /usr/share/munin/munin-graph --cron Nested quantifiers in regex; marked by -- HERE in m/^r??? -- HERE ??(?:=|$)/ at /usr/share/perl5/Munin.pm line 1104. + '[' -x /usr/share/munin/munin-html ']' + nice /usr/share/munin/munin-html Nested quantifiers in regex; marked by -- HERE in m/^r??? -- HERE ??(?:=|$)/ at /usr/share/perl5/Munin.pm line 1104. This looks like a weird field name or label. Can you please send me your /var/lib/munin/datafile ? -jo :-) signature.asc Description: Digital signature
Bug#296452: munin-node: irqstats error
tags 296452 +fixed-upstream thanks, Once upon a time, Charles Fry [EMAIL PROTECTED] sagely scribed: The irqstats plugin gives an error, because it doesn't handle blank lines in /proc/interrupts. A check for blank lines has now been added to the upstream package. Thanks for reporting the bug. :-) -jo signature.asc Description: Digital signature
Bug#296660: munin: The port variable is hardcoded
tags 296660 +unreproducible thanks, Once upon a time, Plamen Tonev [EMAIL PROTECTED] sagely scribed: The problem with munin package is because of the port variable (default is 4949) which is hardcoded in /usr/share/munin/munin-update. On the contrary, the port number is configurable. An example host in munin.conf: [foo.heimen.no] address 127.0.0.1 port 5000 You can also set it at top-level (it will then count for all hosts). My patch is attached. Your patch just makes the default port (which is the one used if you don't define one in munin.conf). -jo :-) signature.asc Description: Digital signature
Bug#296528: munin: graph problems since update
Once upon a time, Charles Fry [EMAIL PROTECTED] sagely scribed: Ever since updating munin/munin-node, I have been experiencing some strange problems with my graphs. All graphs had previously been contiguous. Now some of them are, but some (such as apache_access, apache_process, apache_volume, df, load, and memory) have gaping holes. Can you please check /var/log/munin/munin-update.log, to see if there's anything about what might cause this in it? Even more worrysome, some of the bars on apache_process decend below the x-axis (leaving the graph and covering some graph labels). That's an rrdtool bug. A workaround for this bug is to add -l 0 to the graph_args for the graph. I saw that the apache_processes you posted had the problem, and have added -l 0 to its graph_args in CVS. If you come across any other graphs with the same problem, please let me know. -jo :-) signature.asc Description: Digital signature
Bug#295366: munin-node: The default_plugin_user options is ignored because of a small bug.
tags 295366 +upstream tags 295366 +fixed-upstream thanks, Once upon a time, Csaba MAJOR [EMAIL PROTECTED] sagely scribed: The default_plugin_user options is ignored. It think the following patch should correct this problem: Applied to 1.2 and 1.3 upstream CVS branches. Thanks. :-) -jo :-) signature.asc Description: Digital signature
Bug#291855: munin-node: Please include the enclosed perdition imap proxy plugin
(This plugin is at http://cvs.sourceforge.net/viewcvs.py/munin/munin/node/node.d/perdition.in?rev=1.1 ). Once upon a time, Micah Anderson [EMAIL PROTECTED] sagely scribed: On Mon, 24 Jan 2005, Jimmy Olsen wrote: If you modify your plugin slightly to use COUNTER or DERIVE instead of GAUGE, I'll make it an auto plugin. :-) Same question as before, COUNTER seems counter-intuitive, but I might not understand why, after looking at the different types ABSOLUTE seems right, but now I am not so sure. I forgot to comment on ABSOLUTE in the last mail. ABSOLUTE fails in a several scenarios -- when using multiple servers against one munin-node, and when running the plugin manually. This makes ABSOLUTE a generally bad choice for Munin plugins. Also, which license are your two contributed plugins (perdition and courier_)? GPL? oh, of course, as a debian developer who intends to have these included in the debian package, they definately need to be DFSG compliant, so GPL it away :) I'll add the GPL note at the top. :-) Thanks for contributing. :-) -jo :-) signature.asc Description: Digital signature
Bug#291854: munin-node: Please include the following courier_ plugin
Once upon a time, Micah Anderson [EMAIL PROTECTED] sagely scribed: On Mon, 24 Jan 2005, Jimmy Olsen wrote: If you modify your plugin slightly (so it reports the number of logins/logouts as a COUNTER or DERIVE), and improve the autoconf section to actually check if Courier is in use, I'll make it an auto plugin (auto plugins are automatically probed when installing munin-node). I'd love to modify it so that it can do that, if you can help me figure out where the version is that you modified. After things are checked into CVS, there's a time lag before it appears in the WebCVS interface. It's arrived overnight: http://cvs.sourceforge.net/viewcvs.py/munin/munin/node/node.d/courier_.in?rev=1.2 (The @@SOMETHING@@ variables are substitution variables that are replaced at install-time.) Also -- I don't know the difference between COUNTER and DERIVE, so I did a little searching, and I believe this is the correct information: [...] I dont really understand what a GAUGE is, but thats not what you are asking. A COUNTER seems... counter-intuitive to me, because that means people logging in and out would be graphed in an ever increasing number (600 people logged in today, 600 tomorrow, the graph would then show 1200? this doesn't seem to be appropriate). It seems to me that the most useful graph would be to see how many logins/logouts/disconnects and connects happen over time, and that seems to me to be an Absolute report. A GAUGE is like a speedometer, showing how fast you're driving right now. A COUNTER is like the thing that counts the number of kilometer the car has driven in its lifespan. When rrdtool (which Munin uses as its backend) gets the data, it draws GAUGEs straight out, while it converts COUNTERs to an average of per second (Munin also allows graphing per minute by setting the graph_period option in munin.conf). In other words, you won't get an ever increasing graph because rrdtool treats the data differently. DERIVE is, in effect, a COUNTER which can also go down (we like DERIVE instead of COUNTER for a technical reason which I'll explain further down). GAUGEs are perfect when dealing with plugins like df or load. When we want to measure an ever increasing number, COUNTER/DERIVE is preferable. When we have a choice (like in your case), COUNTER/DERIVE is preferable as it is more accurate. In the case of your plugin, you return the number of logins/logouts since the last time the plugin was run. This breaks if you either run the plugin manually, if you connect the munin-node to several servers, if you force a manual run of munin-cron on the server, etc. If you convert the datatype to COUNTER/DERIVE, Munin stores the _difference_ compared to the last time it ran the plugin. That means that multiple instances, manual runs, ++ are take care of automatically (since the state is in the rrd file, not on the munin-node plugin). COUNTER has one weakness -- the wrap detection. If a counter was, say 54 on the last update, and now it is 12, rrdtool assumes that it must have hit a 32bit wrap barrier and been reset to 0, and you'll get a tall spike in the graph. One way to get around from this is to use DERIVE instead, and set a field.min 0. That way, any values below 0 (e.g. if you go from 54 to 12) will be dropped. HTH, -jo :-) signature.asc Description: Digital signature
Bug#292110: munin-node: postfix_mailstats uses incorrect offset for determining reject code
tags 292110 +fixed-upstream
thanks,
Once upon a time, Micah Anderson [EMAIL PROTECTED] sagely scribed:
The plugin says:
$rejects-{$codes[13]} ++;
That should be a 10, I've attached a patch that changes this.
I've modified the plugin so it catches both cases.
Changes have been made to CVS 1.2 and 1.3.
-jo :-)
signature.asc
Description: Digital signature
Bug#291720: munin-node: postfix_mailstats uses wrong logfile
tags 291720 +upstream +fixed-upstream
thanks,
Once upon a time, Micah Anderson [EMAIL PROTECTED] sagely scribed:
The postfix_mailstats plugin has:
my $LOGFILE = $ENV{'logfile'} || 'syslog';
this should be:
my $LOGFILE = $ENV{'logfile'} || 'mail.log';
Fixed in the 1.2 and 1.3 CVS trees.
-jo :-)
signature.asc
Description: Digital signature
Bug#288395: Fix the amavis plugin
Hi, Once upon a time, Micah Anderson [EMAIL PROTECTED] sagely scribed: This simple patch will fix the amavis plugin for Debian, the previous patch doesn't handle logfile offsets. The amavis plugin really isn't too good (which is why it's still marked as a contrib plugin). There are at least three different versions of logtail out there, some of which complains about -f, some of which complains about the lack of it. I've modified the plugin to try to autodetect when to use -f and when not to. This could be done a lot better, and real autoconf support is still missing. The number of bug reports on this plugin has been quite high compared to other plugins, so it looks like it's a frequently used plugin (even though it isn't auto-enabled on install if amavis is in use). If anybody out there wants to create a proper amavis plugin, my guess is that it would be appreciated by quite a few people. (Please tell me before starting, so you don't waste your time if others are working on it too. :-) -jo :-) signature.asc Description: Digital signature
Bug#291720: Same problem with postfix_mailvolume
tags 291720 +fixed-upstream
thanks,
Once upon a time, Micah Anderson [EMAIL PROTECTED] sagely scribed:
my $LOGFILE = $ENV{'logfile'} || 'syslog';
this should be:
my $LOGFILE = $ENV{'logfile'} || 'mail.log';
Fixed in 1.2 and 1.3 CVS.
-jo :-)
signature.asc
Description: Digital signature
Bug#291849: munin-node: named plugin uses wrong logfile for debian
tags 291849 +fixed-upstream thanks, Once upon a time, Micah Anderson [EMAIL PROTECTED] sagely scribed: The named plugin is setup for the location of the daemon output of solaris, this should be changed to where this file is on Debian. Attached you can find a patch that does this: The plugin now use (in order of preference): - the contents of $logfile - /var/adm/messages - /var/log/daemon.log -jo :-) signature.asc Description: Digital signature
Bug#291854: munin-node: Please include the following courier_ plugin
tags 291854 +fixed-upstream thanks, Once upon a time, Micah Anderson [EMAIL PROTECTED] sagely scribed: Please find attached a plugin to monitor courier logfiles and track logins and logouts based on the courier service. I've added it as a contrib plugin to 1.2 and 1.3. - Made COURIER_LOG location configurable - Made SERVICE overridable - Made TEMP_FILE use mktemp for security reasons - Made LOGTAIL location configurable (I _hate_ that program). - Made the plugin work with non--f logtails. If you modify your plugin slightly (so it reports the number of logins/logouts as a COUNTER or DERIVE), and improve the autoconf section to actually check if Courier is in use, I'll make it an auto plugin (auto plugins are automatically probed when installing munin-node). -jo :-) signature.asc Description: Digital signature
Bug#291855: munin-node: Please include the enclosed perdition imap proxy plugin
tags 291855 +fixed-upstream thanks, Once upon a time, Micah Anderson [EMAIL PROTECTED] sagely scribed: Please find enclosed a plugin that will monitor perdition's logfiles and graph the different service connections and errors. The plugin has been added to the 1.2 and 1.3 CVS, as a contrib plugin. Some minor changes was made: - The location of the PERDITION_LOG was made configurable. - The location of LOGTAIL was made configurable. - Handling of non--f logtail was added. - TEMP_FILE uses mktemp for security. - Superfluous grep when getting field values was removed. If you modify your plugin slightly to use COUNTER or DERIVE instead of GAUGE, I'll make it an auto plugin. :-) Also, which license are your two contributed plugins (perdition and courier_)? GPL? -jo :-) signature.asc Description: Digital signature
Bug#288579: munin-node squid cache incorrectly reports cache size
tags 288579 +fixed-upstream thanks, Once upon a time, Robert NEMKIN [EMAIL PROTECTED] sagely scribed: the squid_cache munin plugin incorrectly reports the squid cache size if more than one cache_dir presents. I don't know, what the correct solution is: drawing a line per cache_dirs or report the sum of all of them. I whis the later. The squid_cache plugins has now been fixed to support multiple cache_dirs. I summed all of them into a single value. The fix is in the 1.2 and 1.3 CVS versions. -jo :-) signature.asc Description: Digital signature
Bug#283622: [munin] add uptime plugin to the plugins list
i like to know when the pc i administer go down or up. :-) so i use the simple attached plugin. i know there are easier ways todo, but still as i look from time to time at the munin page, i prefer to have the overview there. An uptime plugin for linux is already included in the 1.2 and 1.3 upstream branches. In other words, I won't include your plugin in the upstream source. -jo (upstream fellow) :-) signature.asc Description: Digital signature
Bug#291168: /usr/bin/munin-cron: excesively verbose cron job
Hi, Once upon a time, Brian May [EMAIL PROTECTED] sagely scribed: Tore == Tore Anderson [EMAIL PROTECTED] writes: Tore I don't think it's actually Munin who's outputting this, at Tore least I cannot find any trace of that string in the code. I I searched and couldn't find it either. I run the script by hand and it generated the message. It is possible I got the wrong package ;-) I've seen the problem before, and it is indeed in send_nsca. Since regular NSCA isn't affected (only Debian seems to be), I won't fix this in the main package. I've released the last (barring serious bugs) release of the 1.0 series, and I don't see this as a serious bug as there's a pretty easy work-around that can be done in the Debian package of Munin. -jo (upstream) :-) signature.asc Description: Digital signature
