m/update: fix "not a reference at /../Utils.pm"

As Petter Reinholdtsen noticed :

    The issue is that $data in the call to Storable::nstore() is
    undefined.

    This get rid of the warning in the cron email triggered by trying to store
    nothing in /var/lib/munin/htmlconf.storable.tmp.$pid.  But the cron email
    is still sent out, this time with another and more understandable message:

      [FATAL] There is nothing to do here, since there are no nodes with
      any plugins. Please refer to http://munin-monitoring.org/wiki/FAQ_no_graphs

I commited a slighly edited patch, but the effect is exactly the same as the
one that Petter wrote.

Closes: D:696981
Merge branch 'bts/696981-fix-not-a-reference-utils-pm' into stable-2.0
Revert "p/postfix_mail: fix incorrect delivered message count"

This reverts commit d07e7c15d11cebbcdf03c3171f406cd01f39e460.

Reopens: D:675318
p/postfix_mailstats: proper fix, but partial

It only partially handles D:675318, as postfix_mailvolume is not fixed.
That plugin needs a special handling, since the information is on 2 different
lines, and it's not an one-line fix.
Merge branch 'bts/675318-incorrect-postfix-delivery-count' into stable-2.0
ChangeLog: 2.0.24
m/Node: add [INFO] in a log

It isn't used in 2.1 anymore, but it is still mandatory for 2.0.
p/iostat_ios: also support /dev/vdX devices
ip/iostat_ios: also support /dev/xvdX devices

Xen kernels use xvdX:

brw-rw---T 1 root disk 202, 32 Jun 27 00:27 /dev/xvdc
Merge pull request #282 from openquery/xvda

ip/iostat_ios: also support /dev/xvdX devices
Issue warning if no data
Merge pull request #281 from openquery/nodata-upstream-pr-270

Issue warning if no data
m/limits: remove warning about uninitialized

undef severities should just be silenced

Closes: munin-monitoring/munin#304
Merge pull request #306 from steveschnepp/fix/g-304-use-of-uninitialized-value-severities

m/limits: remove warning about uninitialized
p/irqstats: Improve generated labels

Three cosmetical issues with the labels generated by the irqstats
plugin:

1.

The concept of "interrupt domains" is somewhat unknown in the Intel
world. It seems to be quite common on other archs like ARM-based and
powerpc though.

Somewhat guessing from reading the Linux kernel sources, the basic
idea is the interrupt number as seen bei the interrupt controller
("hwirq") do not necessarily match the number the kernel uses
internally and is visible in the first column of /proc/interrupts.
In that case, an additional column contains that hwirq IRQ number¹.

The irqstats plugin is not aware of that and generates a label from
both that number and the actual name, like in

(...)
|            CPU0
(...)
|  25:  492375413  main-interrupt-ctrl  11  eth0
|  33:        949  main-interrupt-ctrl  33  serial
|  74:   15147181  main-interrupt-ctrl  46  f1072004.mdio-bus
(...)
[ /proc/interrupts ]

(...)
| i25.label 11  eth0
| i25.info Interrupt 25, for device(s): 11  eth0
| i25.type DERIVE
| i25.min 0
| i33.label 33  serial
| i33.info Interrupt 33, for device(s): 33  serial
| i33.type DERIVE
| i33.min 0
| i74.label 46  f1072004.mdio-bus
| i74.info Interrupt 74, for device(s): 46  f1072004.mdio-bus
| i74.type DERIVE
| i74.min 0
(...)
[ $(munin-run irqstats config) ]

2.

On kernels with CONFIG_GENERIC_IRQ_SHOW_LEVEL² enabled (powerpc), an
additional column containing "Level" or "Edge" is printed

|            CPU0
(...)
|  19:        745   MPIC 1     19 Level     pata-macio
|  25:          0   MPIC 1     25 Level     VIA-PMU
|  26:          0   MPIC 1     26 Level     keywest i2c
(...)
[ /proc/interrupts ]

3.

In the expample above, the space in the PIC name "MPIC 1"³ causes
additional trouble, "config" suggests the labels as follows

| irqstats.i19.label 1     19 Level     pata-macio
| irqstats.i25.label 1     25 Level     VIA-PMU
| irqstats.i26.label 1     26 Level     keywest i2c

These labels just eat space and are somewhat confusing.

The patch below catches these situations by

1. Dropping that number, unless it's different from the logical
   one. In that case, it is appended to the label.
2. Stripping these strings if present.
3. Wild-guessing. The $type variable is not used by the way but the
   patch creates a value in the intended idea.
   It might be an idea to fix that extra space in the kernel.

Regards,
    Christoph

¹ kernel-git:
    commit v3.10-rc5-20-gc12d2f4
² kernel-git:
    commit v2.6.38-7061-gab7798f
    commit v2.6.39-rc5-148-g94b2c36
³ kernel-git:
    commit v2.6.15-1517-g1beb6a7

Closes: D#770746
Signed-off-by: Steve Schnepp <steve.schnepp@pwkf.org>
Merge branch 'bts/770746-improving-the-label-generated-by-the-irqstats-plugin' into stable-2.0
plugins/df_abs: fix the naming for regular devices

As stated by Christoph Biedl:

Commit a4eb420 was created in the intention to append the mountpoint to
non-device mounts like tmpfs in order to make them unique.

However, the quoting in

+               "/*" )

disabled globbing so this clause will never be hit¹. As a result, the
mountpoint is appended to *all* devices like in

| _dev_vda1__boot.value 19868
| _dev_vda5__.value 165710

This field name change will also break the historic data as the rrd file name
on the master changes accordingly.

It might be an idea to stay that way (I consider that a bad one) but at the
moment the plugin's behaviour matches neither the documention nor the one of
the other df* plugins.

¹ Unless somebody naughty creates a device with literally that name.

Closes: D#770745
Merge branch 'bts/770745-fix-unintended-breakage-in-rrd-file-names' into stable-2.0
p/pgsql: Detect "rc" postgresql versions.

 - Also accept versions ending in "rc\d+"
 - Thanks to Vincas Dargis for bringing it to our attention via the Debian BTS.

Closes: D#770826
Merge branch 'bts/770826-postgresql-plugin-fails-to-find-rc-version' into stable-2.0