Bug#1004421: ITS: cadaver

[Sebastian Harl]

Thanks for reaching out. Yes, I'm totally okay. I should have orphaned this a 
while ago, so this is much appreciated. Thanks!


On 20 May 2022 05:31:31 UTC, Arnaud Rebillout  wrote:
>CC Sebastian Harl in case it helps
>
>Sebastian are you Ok if I take over this package and maintain it within 
>pkg-security-team?
>
>Cheers
>

Bug#912995: FTBFS: missing build-dep on python-packaging

[Sebastian Harl]

Package: ansible
Version: 2.7.1+dfsg-1
Severity: serious
Justification: FTBFS

Hi,

rebuilding ansible 2.7.1 fails when in a clean chroot:

make[2]: Entering directory '/build/1st/ansible-2.7.1+dfsg'
Traceback (most recent call last):
  File "packaging/release/versionhelper/version_helper.py", line 9, in 
from packaging.version import Version, VERSION_PATTERN
ImportError: No module named packaging.version
Makefile:40: *** "version_helper failed".  Stop.

See 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ansible.html

packaging.version is provided by python-packaging.

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x2F1FFCC7 +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#767440: ncmpc: Blanks screen after unpausing

[Sebastian Harl]

tags 767440 + unreproducible
thanks

On Thu, Oct 30, 2014 at 07:18:20PM -0700, Ian Zimmerman wrote:
> When mpd is in a "Paused" state at the time I start ncmpc, and the
> current view is the Queue view (ie. F2), the first time I resume play
> (unpause) the screen goes totally blank.  Switching to any other view
> and back, for instance pressing F1 and then F2, restores normal
> display.
> 
> This happens _only the first time_ I unpause.  When I pause from within
> a running ncmpc and then unpause with the same instance, there is no
> problem.

Thanks for reporting this (a long time ago, sorry!).

I cannot reproduce this with more modern version of ncmpc (0.24 and up)
but I also haven't found a change that clearly relates to that.

Does this still exist for you?

Thanks,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x2F1FFCC7 +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#878348: collectd FTBFS with libsigrok 0.5.0

[Sebastian Harl]

Hi,

On Sun, Oct 22, 2017 at 09:49:43AM +0200, Michael Stapelberg wrote:
> Adrian Bunk  writes:
> > Source: collectd
> > Version: 5.7.2-1
> > Severity: serious
> >
> > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/collectd.html
> >
> > ...
> > checking for LIBSIGROK... no
> > ...
> > configure:40804: checking for LIBSIGROK
> > configure:40811: $PKG_CONFIG --exists --print-errors "libsigrok < 0.4"
> > Requested 'libsigrok < 0.4' but version of libsigrok is 0.5.0
> 
> tokkee, are you on top of this? This bug marks freeradius for
> auto-removal from testing. If you need help with a fix, please let me
> know.

Yes, I have a pending upload to fix it. Thanks for the ping.

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x2F1FFCC7 +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#879471: src:varnish: 5.2 needs a SONAME version bump

[Sebastian Harl]

Package: src:varnish
Version: 5.2.0-1
Severity: serious
Justification: Policy 8.6.2

Hi,

version 5.2 of Varnish introduces a bunch of backward incompatible API
and ABI changes which require a SONAME version bump.

For example, types like VSC_point in /usr/include/varnish/vapi/vsc.h
have changed in incompatible ways (e.g. the 'section' field of the
struct has been removed). This is an incompatible API change causing
other packages to FTBFS (e.g. collectd). Anyway, that's up to those
other packages to fix in new versions.

More importantly, though, the ABI of the library has changed as well.
For example, the VSM_N_Arg symbol has been removed. This causes existing
programs / libraries linked against libvarnishapi1 to fail at runtime
when trying to load the library.

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x2F1FFCC7 +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#852658: collectd-core: Won't start without non-required packages libsensors4 liboping0

[Sebastian Harl]

Hi,

On Sat, Jan 28, 2017 at 11:35:03AM +0100, Marc Fournier wrote:
> On Thu, Jan 26, 2017 at 08:05:06AM +, Jan Huijsmans wrote:
> > Installation of collectd fails on the start of the package.
> > The package misses files from libsensors4 liboping0, but these
> > packages are only recommended or even suggested.
> 
> The configuration file shipped with the collectd package only loads these
> plugins by default:
> 
> marc@lonquimay:~/src/pkg-collectd/debian$ grep ^LoadPlugin collectd.conf
> LoadPlugin syslog
> LoadPlugin battery
> LoadPlugin cpu
> LoadPlugin df
> LoadPlugin disk
> LoadPlugin entropy
> LoadPlugin interface
> LoadPlugin irq
> LoadPlugin load
> LoadPlugin memory
> LoadPlugin processes
> LoadPlugin rrdtool
> LoadPlugin swap
> LoadPlugin users
> 
> None of them depend on libsensors4 or liboping0 (the sensors and ping
> plugins do, but they aren't enabled by default).
> 
> So my guess is that this system previously had a non-default configuration
> (maybe some config snippets in /etc/collectd/collectd.conf.d/ ?) in place,
> and installing/upgrading collectd-core made the missing runtime
> dependencies strike out.
> 
> Are you able to confirm ?

That's my guess as well.

> NB: I agree such a failure is undesirable. The collectd plugin loading
> mechanism could maybe be changed to not abort startup in this case (just
> skip loading the plugin and emit an error message).

I think I disagree. Daemon startup should imho fail so that people
actually notice. Else, you'll be left with a running daemon that does
not behave as expected / configured.

That said, I'd be happy if we could improve the overall situation. It
keeps coming up but I don't have a good idea for how to solve it yet :-/

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x2F1FFCC7 +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#872482: why the further fixup is not needed

[Sebastian Harl]

Hi,

On Fri, Sep 01, 2017 at 07:05:08PM +0100, Luca Boccassi wrote:
> On Wed, 30 Aug 2017 15:05:30 +0100 Luca Boccassi 
> wrote:
> > On Fri, 18 Aug 2017 07:35:20 +0200 Christian Ehrhardt
>  > d...@canonical.com> wrote:
> > > For a grain of confidence and background - Upstream there is also a
> > follow
> > > up fix [1], but that is not needed for your package.
> > > 
> > > The reason is, that this follow up is only needed if dpdk has no
> > > pkg-config, which the 16.11 based package that is in Debian right
> now
> > > already have.
> > > 
> > > [1]: https://github.com/collectd/collectd/pull/2405
> > 
> > The patch I sent actually already has that fix included as well :-)
> > 
> > Maintainers, gentle ping - I would like to upload a new version of
> DPDK
> > to sid (16.11.3) which will include the breaking change for !amd64.
> > 
> > It would be really appreciated if this patch could be looked at. I am
> > more than willing to do the extra work and provide an NMU if time is
> > short on your hands - just let me know if it's acceptable.
> > 
> > Thank you!
> 
> In case it's more convenient, I've sent a pull request on Github:
> 
> https://github.com/collectd/pkg-debian/pull/14

Thank you for reporting this and providing a patch. A PR is super
useful. I merged it and I'm preparing an upload now.

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x2F1FFCC7 +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#867582: shutter: Crashes when running multiple instances

[Sebastian Harl]

Hi,

this seems to be https://bugs.launchpad.net/shutter/+bug/731874

Thanks,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x2F1FFCC7 +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#867582: shutter: Crashes when running multiple instances

[Sebastian Harl]

Package: shutter
Version: 0.93.1-1.3
Severity: normal

Hi,

when running a second instance of 'shutter -s', the first instances
crashes with a segfault. The second instance prints the following:

(shutter:16726): Unique-DBus-WARNING **: Error while sending message:
Message recipient disconnected from message bus without replying

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x2F1FFCC7 +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#819964: collectd: Collectd perl module emits perl warnings

[Sebastian Harl]

forwarded 819964 colle...@verplant.org
thanks

Hi,

On Mon, Apr 04, 2016 at 01:03:15PM +0200, Guillem Jover wrote:
> The Collectd.pm perl module emits perl warnings, which makes checking
> depending perl modules difficult to check for cleanliness:
[…]
>   ,---
>   $ perl -cw Test.pm
>   Bareword "LOG_ERR" not allowed while "strict subs" in use at 
> /usr/share/perl5/Collectd.pm line 165.
>   Bareword "TYPE_CONFIG" not allowed while "strict subs" in use at 
> /usr/share/perl5/Collectd.pm line 119.
[…]

Thanks for reporting this. Unfortunately, this is hard to fix in a
standard Perl setup. The problem is this: Collectd.pm depends on C code
provided by the collectd perl plugin. It's similar to other Perl modules
that wrap C code, except that those would load a shared object file but
the perl plugin depends on collectd's internal API provided by the core
daemon. That is, Collectd.pm would have to dynamically load the collectd
binary and the perl plugin which isn't feasible. Detangling that would
require a major refactoring of collectd.

That said, we could provide another binary, say 'collectd-perl' that
acts like a Perl interpreter. You can think of the perl plugin as a
customized Perl interpreter embedded into collectd, so that's basically
what we'd want. That shouldn't be hard to do and it would provide the
secondary benefit that you could use that to actually test functionality
as well alongside simple compilation tests (perl -c). The only drawback
is that you'd have to use collectd-perl in place of perl for your tests.

Thoughts anyone?

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x2F1FFCC7 +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#846859: collectd: Don't depend on nagios3 which has been removed from unstable

[Sebastian Harl]

retitle 846859 collectd: Don't suggest nagios3 which has been removed from 
unstable
thanks

Hi,

On Sat, Dec 03, 2016 at 08:16:40PM +0100, Bas Couwenberg wrote:
> Please update your package to deal with the nagios3 removal from Debian
> (#845765).

Thanks for reporting this. This means no version of Nagios is available
in Debian anymore, right?

> diff -Nru collectd-5.6.1/debian/control collectd-5.6.1/debian/control
> --- collectd-5.6.1/debian/control 2016-11-01 07:32:47.0 +0100
> +++ collectd-5.6.1/debian/control 2016-12-03 19:53:14.0 +0100
> @@ -242,7 +242,7 @@
>  Architecture: any
>  Depends: ${shlibs:Depends}, ${misc:Depends}
>  Recommends: collectd
> -Suggests: nagios3 | nagios2
> +Suggests: icinga
>  Replaces: collectd (<< 4.6.1-1~)
>  Description: statistics collection and monitoring daemon (utilities)
>   collectd is a small daemon which collects system information periodically 
> and

I suppose quite a few people will still use nagios nevertheless. I'd
hence prefer to change this to icinga | nagios3. That'll make
backporting easier, too. I don't think that'd be a problem for you,
right?

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x2F1FFCC7 +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#845479: src:digikam: Missing icons when used outside a DE

[Sebastian Harl]

Package: src:digikam
Version: 4:5.3.0-1
Severity: normal

Hi,

when using digikam with the Awesome window manager (and presumably
others), no icons show up. Manually installing breeze-icon-theme *and*
selecting an icon theme from Settings > Configure digikam >
Miscellaneous it worked fine.

digikam should imho recommend (or, at the least, suggest)
breeze-icon-theme to make it easier to identify this (weak?) dependency.
Ideally, it would then not need a manual configuration change to
actually pick it up but I understand that this may be a separate feature
request for upstream.

Thanks,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x2F1FFCC7 +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#844997: creepy: Depends on PyQt4.QtWebKit

[Sebastian Harl]

forcemerge 784619 844997
thanks

On Sat, Nov 19, 2016 at 10:43:10AM +0100, Sebastiaan Couwenberg wrote:
> On 11/19/2016 10:25 AM, Sebastian Harl wrote:
> > creepy depends on PyQt4.QtWebKit:
> > 
> >   % creepy
> >   Traceback (most recent call last):
> > File "/usr/bin/creepy", line 19, in 
> >   from PyQt4.QtWebKit import QWebPage, QWebSettings
> >   ImportError: No module named QtWebKit
> > 
> > The package only depends on python-qt4 which does not seem sufficient to
> > satisfy this. In unstable python-pyqt5.qtwebkit is available but no
> > PyQt4 variant thereof.
> 
> What's the value of this bugreport over #784619?

Oops. For some reason I had missed that other report. Sorry.

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x2F1FFCC7 +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#844997: creepy: Depends on PyQt4.QtWebKit

[Sebastian Harl]

Package: creepy
Version: 1.4.1-5
Severity: serious
Justification: Policy 3.5

Hi,

creepy depends on PyQt4.QtWebKit:

  % creepy
  Traceback (most recent call last):
File "/usr/bin/creepy", line 19, in 
  from PyQt4.QtWebKit import QWebPage, QWebSettings
  ImportError: No module named QtWebKit

The package only depends on python-qt4 which does not seem sufficient to
satisfy this. In unstable python-pyqt5.qtwebkit is available but no
PyQt4 variant thereof.

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x2F1FFCC7 +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#842326: ncmpc: NMU uploaded in deferred/queue

[Sebastian Harl]

Hi,

On Thu, Nov 10, 2016 at 08:34:44AM +0100, Gianfranco Costamagna wrote:
> On Mon, 31 Oct 2016 14:26:57 +0100 Gianfranco Costamagna 
>  wrote:
> > I uploaded the following NMU in deferred/10, please let me know if I can 
> > speed it up or cancel it
> > 
> > Attaching the debdiff for the new release (mostly autoconf fixes), and the 
> > filtered debdiff for the debian directory.
> > 
> 
> attaching the new debdiffs, since I forgot to close this bug

Thank you very much for taking care of this.

Merged as https://git.tokkee.org/?p=pkg-ncmpc.git;h=ncmpc-0.25-0.1

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x2F1FFCC7 +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#835703: nut: FTBFS: dh_makeshlibs: failing due to earlier errors

[Sebastian Harl]

Hi,

On Sun, Aug 28, 2016 at 12:27:09PM +0200, Lucas Nussbaum wrote:
> Source: nut
> Version: 2.7.4-3
> Severity: serious

> During a rebuild of all packages in sid, your package failed to build on
> amd64.

> > dpkg-gensymbols: warning: some new symbols appeared in the symbols file: 
> > see diff output below
> > dpkg-gensymbols: warning: some symbols or patterns disappeared in the 
> > symbols file: see diff output below
> > dpkg-gensymbols: warning: debian/libnutclient0/DEBIAN/symbols doesn't match 
> > completely debian/libnutclient0.symbols
[…]

This looks like a rather straight-forward issue, but I'm not into the
magic of C++ symbol files much ;-) Anyway I can help with this?

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x2F1FFCC7 +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#657877: collectd: Does not try to reconnect when rrd daemon dies

[Sebastian Harl]

Hi,

On Thu, Aug 20, 2015 at 11:40:13AM +0200, Sebastian Harl wrote:
> On Sun, Jan 29, 2012 at 04:20:14PM +0100, Matthias Urlichs wrote:
> > When collectd logs via rrdcached, and rrdcached is restarted, 
> > collectd spews errors instead of trying to reconnect.
> 
> Thanks for reporting this and sorry for the slow reply :-/
> 
> This issue is related to how the rrdcached client library works. It only
> supports a single connection and caches that in a global variable.
> collectd calls rrdc_connect on each write but the function will simple
> return success if it succeeded previously.
> 
> I think what we'll have to do is
> (a) in collectd, close the connection on error and, thus, trigger an
> actual reconnect; possibly use exponential back-off

I've got https://github.com/collectd/collectd/pull/1959 pending for
this.

> (b) improve the RRDtool API ;-)

And https://github.com/oetiker/rrdtool-1.x/pull/742 for this.

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x2F1FFCC7 +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#600433: collectd: rrd: gets terribly confused when entering DST (daylight savings time)

[Sebastian Harl]

severity 600433 normal
thanks

On Sun, Oct 17, 2010 at 11:02:11AM -0200, Henrique de Moraes Holschuh wrote:
> On Sun, 17 Oct 2010, Florian Forster wrote:
> > On Sun, Oct 17, 2010 at 03:32:36AM -0200, Henrique de Moraes Holschuh wrote:
> > > collectd[2139]: uc_update: Value too old:name = 
> > > /temperature-temp1; value time = 1287260393; last cache update = 
> > > 1287260393;
> > 
> > If the timestamp was influenced by the timezone shift, "value time"
> > should be 1-3600 seconds smaller than "last cache update" [0]. The two
> > values are identical, though, which is 99.9% of all cases means that the
> > identifier ((file)name of the data) is not unique. Maybe the names
> 
> If you mean the full path, then there is no colision.  If you mean just the
> file-name (temperature-temp1), then there are many colisions.  I don't think
> that was it.
> 
> I did better checking now (heh, "repeats the error of the past" seems to
> apply to me very well...).  It was a few hours away from the DST change, so
> my report was utterly bogus.  I apologise for that.
> 
> It happened three times, to all sensors, including those who would have no
> collision across different directories (i.e. unique filename).  Looks more
> like collectd tried to store the same data twice.
> 
> It all happened on the same "minute".  Only other event of note is that cron
> started the cron.hourly scripts at that same minute, a few seconds earlier.
> However, I am _not_ seeing trouble every hour.

Is this still happening? I believe there were a few fixes that could be
related to this in the past years. If it's still happening, we'll have
to look into more details.

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x2F1FFCC7 +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#833013: collectd-core: Network plugin fails to load

[Sebastian Harl]

Hi,

On Tue, Aug 02, 2016 at 10:45:50PM +0200, Dejan SANADER wrote:
> Looks like a libgcrypt >= 1.6 is mandatory now...
> 
> https://github.com/collectd/collectd/blob/master/src/network.c#L504

Thanks for the additional info. It's actually the other way around.
gcry_control(GCRYCTL_SET_THREAD_CBS) is only used for libgcrypt < 1.6.

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x2F1FFCC7 +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#833013: collectd-core: Network plugin fails to load

[Sebastian Harl]

tags 833013 + wheezy
thanks

Hi,

On Sat, Jul 30, 2016 at 11:16:29PM +0200, Antoine Sirinelli wrote:
> Since the latest security update, collected cannot load anymore the
> network plugin. Since this plugin is used to transfer the measurements
> to other hosts, it makes collectd completely useless for me.
> 
> Here is the error messages:
> 
> network plugin: gcry_control (GCRYCTL_SET_THREAD_CBS) failed: Not supported
> Initialization of plugin `network' failed with status -1. Plugin will be 
> unloaded.

Thanks for reporting this. That failure is a regression in
5.1.0-3+deb7u1 but it seems to have surfaced an actual (potentially
severe) underlying issue that already existed before. It's specific to
Wheezy.

Just before the collectd error messages, you should see the following in
syslog:
Libgcrypt warning: missing initialization - please fix the application

What happens is that gcrypt (apparently) is initialized before the call
to gcry_control(GCRYCTL_SET_THREAD_CBS). Since that call is then trying
to change the settings in an unsupported way (cannot change threading
behavior after initialization), we're seeing this error.

Now, the actual problem is that this means gcrypt is not initialized
correctly. Given the multi-threaded nature of collectd, I believe that
this may potentially mean undefined behavior or crashes in the gcrypt
code in the network plugin.

I'll need to dig further into why this is happening in the first place
(why is gcrypt already initialized at this point?).

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x2F1FFCC7 +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#833013: collectd-core: Network plugin fails to load

[Sebastian Harl]

Hi,

On Wed, Aug 03, 2016 at 10:53:39AM +0200, Sebastian Harl wrote:
> On Sat, Jul 30, 2016 at 11:16:29PM +0200, Antoine Sirinelli wrote:
> > Since the latest security update, collected cannot load anymore the
> > network plugin. Since this plugin is used to transfer the measurements
> > to other hosts, it makes collectd completely useless for me.
> > 
> > Here is the error messages:
> > 
> > network plugin: gcry_control (GCRYCTL_SET_THREAD_CBS) failed: Not supported
> > Initialization of plugin `network' failed with status -1. Plugin will be 
> > unloaded.
> 
> Thanks for reporting this. That failure is a regression in
> 5.1.0-3+deb7u1 but it seems to have surfaced an actual (potentially
> severe) underlying issue that already existed before. It's specific to
> Wheezy.
> 
> Just before the collectd error messages, you should see the following in
> syslog:
> Libgcrypt warning: missing initialization - please fix the application
> 
> What happens is that gcrypt (apparently) is initialized before the call
> to gcry_control(GCRYCTL_SET_THREAD_CBS). Since that call is then trying
> to change the settings in an unsupported way (cannot change threading
> behavior after initialization), we're seeing this error.
> 
> Now, the actual problem is that this means gcrypt is not initialized
> correctly. Given the multi-threaded nature of collectd, I believe that
> this may potentially mean undefined behavior or crashes in the gcrypt
> code in the network plugin.
> 
> I'll need to dig further into why this is happening in the first place
> (why is gcrypt already initialized at this point?).

I believe the initialization happens during collectd's configuration
phase. The following upstream commit (which is part of the releases in
Jessie and onwards) fixes the issue:
https://github.com/collectd/collectd/commit/0ec776abf45ef3989f38d966e74b588f9ef15ebe

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x2F1FFCC7 +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#832507: Heap overflow in the network plugin

[Sebastian Harl]

Hi,

On Tue, Jul 26, 2016 at 10:48:58AM +0200, Florian Forster wrote:
> Emilien Gaspar has identified a heap overflow in collectd's network
> plugin which can be triggered remotely and is potentially exploitable.
> The identifier CVE-2016-6254 has been assigned to this issue.
> 
> This issue has been fixed in the released 5.5.2 and 5.4.3.
> Please update the version provided by Debian to a non-vulnerable
> version.
> 
> For the oldstable and stable branches, please add the following patches
> to fix the issue:
> 
> https://github.com/collectd/collectd/commit/b589096f907052b3a4da2b9ccc9b0e2e888dfc18

Thank you for reporting this.

> https://github.com/collectd/collectd/commit/8b4fed9940e02138b7e273e56863df03d1a39ef7
> 
> The second patch is unrelated to CVE-2016-6254. It fixes an
> initialization issue with libgcrypt which could theoretically lead to a
> half-initialized library being used.

I've reported a separate bug for this issue:
https://bugs.debian.org/832577

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x2F1FFCC7 +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#832577: collectd: gcrypt may be used half-initialized missing security settings

[Sebastian Harl]

Package: collectd
Version: 5.1.0-3
Severity: important
Tags: patch, security, upstream, fixed-upstream

Hi,

a team of security researchers at Columbia University and the University
of Virginia discovered that GCrypt's gcry_control is sometimes called
without checking its return value for an error. This may cause the
program to be initialized without the desired, secure settings.

The issue was reported in
https://github.com/collectd/collectd/issues/1665

The issue is already fixed upstream:
https://github.com/collectd/collectd/commit/8b4fed9940e02138b7e273e56863df03d1a39ef7

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x2F1FFCC7 +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#830623: RM: liblingua-de-ascii-perl -- ROM; ancient; unused

[Sebastian Harl]

Package: ftp.debian.org
Severity: normal

This package is ancient and I long forgot what it was originally used
for. Popcon is extremely low, so even though this is a low-effort
package, it should rather be dropped from the archive. It's already gone
from testing (since it still used dh compat v4).

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x2F1FFCC7 +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#829634: collectd: Please rebuild with linux-libc-dev >= 4.6

[Sebastian Harl]

Hi,

On Mon, Jul 04, 2016 at 10:52:51PM +0200, Gábor Gombás wrote:
> The size of the rtnl_link_stats64 structure changed in Linux 4.6 by
> commit 6e7333d315a768170a59ac771297ee0551bdddbf, which causes the
> netlink plugin to fail:

Thanks for reporting this!

Ftr, this is a link to the commit:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6e7333d315a768170a59ac771297ee0551bdddbf

> Jul  4 22:14:28 host collectd[3022]: netlink plugin: link_filter_cb: 
> IFLA_STATS64 mnl_attr_validate2 failed.
> Jul  4 22:14:28 host collectd[3022]: netlink plugin: ir_read: 
> mnl_socket_recvfrom failed.
> Jul  4 22:14:28 host collectd[3022]: read-function of plugin `netlink' 
> failed. Will suspend it for 120.000 seconds.
> 
> Recompiling with headers from 4.6 should fix this (and would make the
> plugin fail with older kernels). The right fix would be to handle such
> structure extensions gracefully, but after a quick look, the libmnl
> library which the netlink plugin uses does not seem to have built-in
> support for that.

I think this will continue to work with older kernels after recompiling
it. The change to the struct is backward-compatible since the new field
is appended to the end and (from skimming over some of the code) it
seems like other places handle this fine. The problem we encountered
here is that the size we provided was smaller than expected.

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x2F1FFCC7 +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#825606: collectd: B-D: libsigrok-dev unavailable on kfreebsd

[Sebastian Harl]

On Tue, Jul 05, 2016 at 01:50:31PM +0200, Sebastian Harl wrote:
> On Mon, Jul 04, 2016 at 12:55:17AM +0200, Andreas Beckmann wrote:
> > On Sat, 28 May 2016 08:24:52 +0200 Andreas Beckmann <a...@debian.org> wrote:
> > > the recently added B-D: libsigrok-dev is only available on Linux.
> > > If this can be optional, please restrict it to [linux], otherwise please
> > > request decrufting of the outdated binary packages on kfreebsd-*.
> > 
> > I haven't heard something within the last month, so I'm requesting the 
> > decrufting.
> 
> Sorry for the late reply. This can be made optional. We'll fix it in
> collectd.

Fixed in
https://github.com/collectd/pkg-debian/commit/5c82d9614c83bbb246c42d7a499f5f65f3ac8bfc

Will go into the next upload.

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x2F1FFCC7 +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#825606: collectd: B-D: libsigrok-dev unavailable on kfreebsd

[Sebastian Harl]

reassign -1 src:collectd
severity -1 important
retitle -1 collectd: B-D: libsigrok-dev unavailable on kfreebsd
thanks

On Mon, Jul 04, 2016 at 12:55:17AM +0200, Andreas Beckmann wrote:
> On Sat, 28 May 2016 08:24:52 +0200 Andreas Beckmann  wrote:
> > the recently added B-D: libsigrok-dev is only available on Linux.
> > If this can be optional, please restrict it to [linux], otherwise please
> > request decrufting of the outdated binary packages on kfreebsd-*.
> 
> I haven't heard something within the last month, so I'm requesting the 
> decrufting.

Sorry for the late reply. This can be made optional. We'll fix it in
collectd.

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x2F1FFCC7 +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#803163: collectd: Please run autoreconf

[Sebastian Harl]

On Mon, May 30, 2016 at 11:06:32AM +0200, Marc Fournier wrote:
> But as there doesn't seem to be any reason to hold this back for the
> combination of recent autoconf & collectd versions, I suggest running
> autoreconf for the stable/testing/unstable lines, but disabling it for the
> backports (+ other non-debian lines such as the nightly builds).
> 
> Unless Tokkee has any comments on this, I'll prepare a 5.5.1-4 release
> shortly including Guillem's patch.

SGTM. Thanks!

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x2F1FFCC7 +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#614602: long filenames and loop devices are a problem?

[Sebastian Harl]

forwarded 614602 https://github.com/collectd/collectd/pull/1120
thanks

Hi,

On Tue, Feb 22, 2011 at 04:24:19PM +0100, Rainer Zocholl wrote:
> The log fills is filling up with this missleading error messages below.
> That seems to be caused by too small buffer sizes
> for "DF" filename generation and the usage of df on a loop mount.
>   
> 
> 1. Maybe a message complaining "File is ready in use" would ease 
>error finding a lot if this for 99,9% true 
> 2. The buffer length for filename should be made longer or 
> 3. if the filename is to be truncated a warning message should be issued
> 4. The df_plugin should ignore "loop" mounts as the
>df command is not delivering any data!

https://github.com/collectd/collectd/pull/1120 discusses a new buffer
size and dynamically allocated buffers to solve the issue. Better
warnings would be good but I think the actual issue should really be
fixed.

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x2F1FFCC7 +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#822397: FTBFS: configure: error: "Some plugins are missing dependencies

[Sebastian Harl]

On Sat, May 21, 2016 at 04:46:01PM +0200, Santiago Vila wrote:
> I'm making the usual tidy up here:
> 
> Reassign to linux because that's where the real bug was.
> Affects because it made this package to FTBFS.

Thanks!

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x2F1FFCC7 +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#822397: FTBFS: configure: error: "Some plugins are missing dependencies

[Sebastian Harl]

Hi,

On Sat, Apr 23, 2016 at 06:35:37PM -0700, Martin Michlmayr wrote:
> This package fails to build in unstable:

Thanks for reporting this!

> > iptables  . . . . . . no (dependency error)
> 
> ^

Here's the underlying problem (from config.log):

  configure:21357: checking libiptc/libiptc.h usability
  configure:21357: x86_64-linux-gnu-gcc -c -g -O2 -fstack-protector-strong 
-Wformat -Werror=format-security -Wall -Wno-error=deprecated-declarations 
-Wdate-time -D_FORTIFY_SOURCE=2 -I/<>/debian/include -UCONFIGFILE -
  DCONFIGFILE='"/etc/collectd/collectd.conf"'  conftest.c >&5
  In file included from /usr/include/libiptc/ipt_kernel_headers.h:13:0,
   from /usr/include/libiptc/libiptc.h:6,
   from conftest.c:230:
  /usr/include/linux/if.h:71:2: error: redeclaration of enumerator 'IFF_UP'
IFF_UP= 1<<0,  /* sysfs */
^
  /usr/include/net/if.h:44:5: note: previous definition of 'IFF_UP' was here
   IFF_UP = 0x1,  /* Interface is up.  */

This is one of the usual sort of kernel header problems :-/
Not sure yet what the right solution would be.

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x2F1FFCC7 +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#806199: collectd: Please split each plugin config into a conffile snippet

[Sebastian Harl]

Hi,

On Fri, Nov 27, 2015 at 11:28:44AM +0100, Guillem Jover wrote:
> On Wed, 2015-11-25 at 15:13:23 +0100, Sebastian Harl wrote:
> > On Wed, Nov 25, 2015 at 11:35:11AM +0100, Guillem Jover wrote:
> > > To ease customization, it would be nice if each default plugin
> > > configuration (LoadPlugin and Plugin stanzas), or at least related
> > > groups of them, could be moved into their own plugin-(name|group).conf
> > > under /etc/collectd/collectd.conf.d/, so that they could be modified
> > > locally w/o triggering a conflict with changes on the rest of the
> > > conffile on upgrades, or to be able to disable specific plugins by
> > > just renaming them.
> 
> > I considered a plugins.available.d / plugins.enabled.d approach before,
> > similar to how Apache or Nginx work on Debian. My only concern is that
> > it would be a long list of files some of which would only include the
> > LoadPlugin line since there's no further configuration to a lot of
> > plugins. This may be less convenient to what we have today, so I'm not
> > sure about the best option. Hence, I'd be happy about any feedback on
> > this.
> 
> Right. I guess an option could be to start by splitting out config
> fragmants for plugins that have a Plugin stanzas. That should help
> with the bulk of the customizations. Having to deal with the main
> config that only contains the remaining list of LoadPlugin would be
> easier in comparison.

So, the overall goal here is to improve ease of use. Updating and
merging the config is one aspect imho and consistency another. Having
things in "one place" also plays into it imho (easy to search for
stuff). I think consistency speaks against a mixed approach so I'd
(lightly) tend towards splitting out *all* plugins into separate files
if we go that route.

What'd you think about splitting the config into one file per plugin
with the LoadPlugin statement and commented Plugin blocks and then also
providing a combined file as, for example, collectd.conf.sample to make
it easier for people to switch back?

> > I think groups are even harder to get right because I don't think
> > there's much of natural grouping so any approach would be very use-case
> > specific.
> 
> With groups, I was thinking on basic grouping for very strongly related
> ones such as curl*, membache[cd] or redis and write_redis, but perhaps
> even then there's no point in grouping these?

I think there isn't. I don't think there's a higher correlation between
using those plugins in parallel than any other plugins (maybe it's even
lower because you'd usually only use one from each group).

Thanks for your feedback so far!

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x2F1FFCC7 +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#806199: collectd: Please split each plugin config into a conffile snippet

[Sebastian Harl]

Hi,

On Wed, Nov 25, 2015 at 11:35:11AM +0100, Guillem Jover wrote:
> To ease customization, it would be nice if each default plugin
> configuration (LoadPlugin and Plugin stanzas), or at least related
> groups of them, could be moved into their own plugin-(name|group).conf
> under /etc/collectd/collectd.conf.d/, so that they could be modified
> locally w/o triggering a conflict with changes on the rest of the
> conffile on upgrades, or to be able to disable specific plugins by
> just renaming them.

Thanks for the feedback.

I considered a plugins.available.d / plugins.enabled.d approach before,
similar to how Apache or Nginx work on Debian. My only concern is that
it would be a long list of files some of which would only include the
LoadPlugin line since there's no further configuration to a lot of
plugins. This may be less convenient to what we have today, so I'm not
sure about the best option. Hence, I'd be happy about any feedback on
this.

I think groups are even harder to get right because I don't think
there's much of natural grouping so any approach would be very use-case
specific.

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x2F1FFCC7 +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#799732: dh-strip-nondeterminism: dh_strip_nondeterminism uses get_source_date_epoch which isn't available (yet)

[Sebastian Harl]

Package: dh-strip-nondeterminism
Version: 0.011-1
Severity: serious
Justification: Policy 3.5

Hi,

version 0.011-1 switched from using $dh{DATE} to get_source_date_epoch()
which was introduced (exported) in debhelper on Aug 12 [1]. However,
there was no release of debhelper since then. The latest version is
9.20150811. Even if it was available, dh-strip-nondeterminism should use
a versioned dependency to make this clear. This let's the script fail
whenever it finds non-deterministic files.

Cheers,
Sebastian

[1] 
https://github.com/Debian/debhelper/commit/0939d0910aed780e4767077d69c23eb7b0a1a8d6

-- System Information:
Debian Release: 6.0.10
  APT prefers oldoldstable-updates
  APT policy: (500, 'oldoldstable-updates'), (500, 'oldoldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-vserver-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/bash

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x2F1FFCC7 +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#588153: closed by Marc Fournier marc.fourn...@camptocamp.com (Bug#588153: fixed in collectd 5.5.0-1)

[Sebastian Harl]

Hi,

On Fri, Aug 21, 2015 at 06:42:17PM +0100, Ian Jackson wrote:
 Debian Bug Tracking System writes (Bug#588153 closed by Marc Fournier 
 marc.fourn...@camptocamp.com (Bug#588153: fixed in collectd 5.5.0-1)):
   - Add Build-depend on libudev-dev (used by disk plugin to enable
 udev-based device renaming on Linux) (Closes: #588153, #632936).
 
 This doesn't seem to be anything related to my bug report.  But I
 think in fact #632936 is similar to my bug report and 

The udev-based device renaming (indirectly) addresses your bug by
providing stable identifiers.

   - The disk plugin now (optionally) supports instance names
 based on a udev attribute; thanks to Trent W. Buck for
 reporting this (Closes: #632936).
 
 this seems to be actually relevant.
 
 I note that #632936 appears twice in the changelog.

Oops. I added this entry and missed that the bug was already referenced
in the other entry.

 But anyway if #632936 is fixed I think #588153 is too, pretty much.

I think so, too. Note that filtering is applied after renaming the
device which should cover the other aspect of your original report. If
there's anything else, please reopen or open a new bug.

 I thought I would email you about these changelog oddities just to
 double-check.

Thanks for checking.

Cheers,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x2F1FFCC7 +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#657877: collectd: Does not try to reconnect when rrd daemon dies

[Sebastian Harl]

Hi,

On Sun, Jan 29, 2012 at 04:20:14PM +0100, Matthias Urlichs wrote:
 When collectd logs via rrdcached, and rrdcached is restarted, 
 collectd spews errors instead of trying to reconnect.

Thanks for reporting this and sorry for the slow reply :-/

This issue is related to how the rrdcached client library works. It only
supports a single connection and caches that in a global variable.
collectd calls rrdc_connect on each write but the function will simple
return success if it succeeded previously.

I think what we'll have to do is
(a) in collectd, close the connection on error and, thus, trigger an
actual reconnect; possibly use exponential back-off
(b) improve the RRDtool API ;-)

Cheers,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x2F1FFCC7 +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#747863: systemd service fails by default and causes package install failure

[Sebastian Harl]

Hi,

On Mon, Feb 23, 2015 at 10:58:12AM -0500, Matthew Gabeler-Lee wrote:
 Unfortunately this bug is still present.  A virgin install of nut-client
 results in a service start failure and thus package install failure.
 
 $ sudo systemctl status nut-monitor.service 
 ● nut-monitor.service - Network UPS Tools - power device monitor and shutdown 
 controller
Loaded: loaded (/lib/systemd/system/nut-monitor.service; disabled)
Active: failed (Result: resources) since Mon 2015-02-23 10:56:03 EST; 1min 
 3s ago
   Process: 7398 ExecStart=/sbin/upsmon (code=exited, status=0/SUCCESS)
 
 Feb 23 10:56:03 harkonnen upsmon[7398]: upsmon disabled, please adjust the 
 configuration to your needs
 Feb 23 10:56:03 harkonnen upsmon[7398]: Then set MODE to a suitable value in 
 /etc/nut/nut.conf to enable it
 Feb 23 10:56:03 harkonnen systemd[1]: Failed to start Network UPS Tools - 
 power device monitor and shutdown controller.
 Feb 23 10:56:03 harkonnen systemd[1]: Unit nut-monitor.service entered failed 
 state.

I can reproduce the problem as well:

# systemctl status nut-monitor.service
● nut-monitor.service - Network UPS Tools - power device monitor and shutdown 
controller
   Loaded: loaded (/lib/systemd/system/nut-monitor.service; disabled)
   Active: failed (Result: resources) since Sun 2015-03-01 13:16:49 CET; 8s ago
  Process: 25872 ExecStart=/sbin/upsmon (code=exited, status=0/SUCCESS)

Mar 01 13:16:49 whisky upsmon[25872]: upsmon disabled, please adjust the 
configuration to your needs
Mar 01 13:16:49 whisky upsmon[25872]: Then set MODE to a suitable value in 
/etc/nut/nut.conf to enable it
Mar 01 13:16:49 whisky systemd[1]: PID file /var/run/nut/upsmon.pid not 
readable (yet?) after start.
Mar 01 13:16:49 whisky systemd[1]: Failed to start Network UPS Tools - power 
device monitor and shutdown controller.
Mar 01 13:16:49 whisky systemd[1]: Unit nut-monitor.service entered failed 
state.

That is, the problem is that systemd will still expect
/var/run/nut/upsmon.pid to be present after attempting to start upsmon.

I think that MODE=none should no longer be a valid option when using
systemd as you'd then use 'systemctl disable' instead. I don't know
systemd very well, so there could be other options as well and/or maybe
a way to disable upsmon in systemd by default after installing it.

Anyway, I tend to think that dropping systemd support might still be a
good option but you should talk to the release team before. It would be
great if we can get a fix into testing as a removal would affect other
packages (e.g. collectd) as well.

Let me know if I can help.

Thanks,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x2F1FFCC7 +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#779483: collectd: Fails to install if no FQDN domain name

[Sebastian Harl]

forwarded 779483 colle...@verplant.org
thanks

Hi,

On Sun, Mar 01, 2015 at 11:05:28AM +0100, s3v wrote:
 attempting to install this package...
 
   # apt-get install collectd
[…]
   Setting up collectd (5.4.1-6) ...
   Job for collectd.service failed. See 'systemctl status
 collectd.service' and 'journalctl -xn' for details.
   invoke-rc.d: initscript collectd, action restart failed.
   dpkg: error processing package collectd (--configure):
   subprocess installed post-installation script returned error exit
 status 1
   Processing triggers for libc-bin (2.19-15) ...
   Errors were encountered while processing:
   collectd
   E: Sub-process /usr/bin/dpkg returned an error code (1)
 
   # systemctl -l status collectd.service
 
   ● collectd.service - LSB: manage the statistics collection daemon
 Loaded: loaded (/etc/init.d/collectd)
 Active: failed (Result: exit-code) since dom 2015-03-01 10:26:49
 CET; 2min 13s ago
 Process: 6119 ExecStop=/etc/init.d/collectd stop (code=exited,
 status=0/SUCCESS)
 Process: 6127 ExecStart=/etc/init.d/collectd start (code=exited,
 status=1/FAILURE)
 
 mar 01 10:26:49 s3v3land collectd[6130]: Looking up s3v3land
 failed. You have set the FQDNLookup option,
 but I cannot resolve my hostname to a fully qualified domain
 name. Please fix the network configuration.
 mar 01 10:26:49 s3v3land collectd[6127]: Starting statistics
 collection and monitoring daemon: collectd
 not starting, configuration error failed!
 mar 01 10:26:49 s3v3land systemd[1]: collectd.service: control
 process exited, code=exited status=1
 mar 01 10:26:49 s3v3land systemd[1]: Failed to start LSB: manage
 the statistics collection daemon.
 mar 01 10:26:49 s3v3land systemd[1]: Unit collectd.service
 entered failed state.
 
 The error occurs if /etc/hosts hasn't FQDN domain name:
 
 127.0.0.1   localhost
 192.168.1.3 s3v3land.FOO
 
 # The following lines are desirable for IPv6 capable hosts
 ::1 localhost ip6-localhost ip6-loopback
 ff02::1 ip6-allnodes
 ff02::2 ip6-allrouters
 
 After removing FOO from /etc/hosts file, the problem disappears
 and package installation ends fine.
 
 Can you provide some warnings regarding incorrect syntax in
 etc/hosts but, despite that, allowing a normal installation of the
 package?

Thanks for reporting this. By default, the Debian package configuration
uses 'FQDNLookup true' and I think it makes sense to abort if the lookup
fails. However, I think we can make that optional by allowing a third
value (besides true and false) like allow-fallback or something
which I could then use in the default package configuration.

With this email, I forwarded the issue to the upstream mailing list for
further comments.

Cheers,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x2F1FFCC7 +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#770680: collectd: please backport fix for segfault in lvm.c

[Sebastian Harl]

forcemerge 747093 770680
thanks

On Sun, Nov 23, 2014 at 10:23:05AM +0100, Marc Fournier wrote:
 A fix for #747093 is available upstream. I believe it should be included
 in the package shipped with jessie, as it prevents collectd from
 crashing in a pretty common situation.
 
 This patch will be part of upcoming bugfix release 5.4.2 and can be
 retrieved at this address:
 https://github.com/collectd/collectd/commit/25d7de930baa8a2

Thanks for reporting this. The same issue was also reported in #747093.

Cheers,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x2F1FFCC7 +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#770719: unblock: collectd/5.4.1-6

[Sebastian Harl]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package collectd

This is a request for a pre-approval. The package has not been uploaded
to unstable yet. The new version fixes various important bugs causing
segfaults or lockups in either collectd or related software. All patches
are already applied upstream and will be part of the next upstream patch
release (which didn't come out in time for the freeze, thus I extracted
all important fixes). Here's a summary of the changes; a full debdiff is
attached:

  collectd (5.4.1-6) unstable; urgency=medium
  
* debian/patches:
  - Added bts770681_riemann_ack: upstream fix for the write_riemann plugin
to avoid locking up a remote Riemann instance; thanks to Marc Fournier
for reporting this (Closes: #770681).
  - Added bts747093_lvm_segfault: upstream fix for a segfault in the LVM
plugin; thanks to Bernd Zeimetz and Marc Fournier for reporting this
(Closes: #747093).
  - Added bts770683_curl_init: upstream fix for a segfault in plugins using
libcurl caused by concurrent memory access; thanks to Marc Fournier for
reporting this (Closes: #770683, cf. #735173).
  - Added bts750440_config_segfault: upstream fix for a segfault when
including empty config files; thanks to Bernd Zeimetz and Marc Fournier
for reporting this (Closes: #750440, #770685).
  - Added bts770688_snmp_memleak: upstream fix for a memory leak in the
SNMP plugin; thanks to Marc Fournier for reporting this
(Closes: #770688).
  - Added bts770690_java_jni_thread_detach: upstream fix for locking up the
Java plugin by not properly detaching from the JVM in error conditions;
thanks to Marc Fournier for reporting this (Closes: #770690).
  - Added bts770693_timestamps: upstream fix for handling internal
timestamps; thanks to Marc Fournier for reporting this (Closes: #770693)
  - Added bts770694_loglevel: upstream fix to correct logging behavior when
using an invalid log level; thanks to Marc Fournier for reporting this
(Closes: #770694, #687067).
  
   -- Sebastian Harl tok...@debian.org  Sun, 23 Nov 2014 15:27:15 +0100

unblock collectd/5.4.1-6

-- System Information:
Debian Release: 6.0.10
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-vserver-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/bash

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x2F1FFCC7 +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin

diff -u collectd-5.4.1/debian/changelog collectd-5.4.1/debian/changelog
--- collectd-5.4.1/debian/changelog
+++ collectd-5.4.1/debian/changelog
@@ -1,3 +1,32 @@
+collectd (5.4.1-6) unstable; urgency=medium
+
+  * debian/patches:
+- Added bts770681_riemann_ack: upstream fix for the write_riemann plugin
+  to avoid locking up a remote Riemann instance; thanks to Marc Fournier
+  for reporting this (Closes: #770681).
+- Added bts747093_lvm_segfault: upstream fix for a segfault in the LVM
+  plugin; thanks to Bernd Zeimetz and Marc Fournier for reporting this
+  (Closes: #747093).
+- Added bts770683_curl_init: upstream fix for a segfault in plugins using
+  libcurl caused by concurrent memory access; thanks to Marc Fournier for
+  reporting this (Closes: #770683, cf. #735173).
+- Added bts750440_config_segfault: upstream fix for a segfault when
+  including empty config files; thanks to Bernd Zeimetz and Marc Fournier
+  for reporting this (Closes: #750440, #770685).
+- Added bts770688_snmp_memleak: upstream fix for a memory leak in the
+  SNMP plugin; thanks to Marc Fournier for reporting this
+  (Closes: #770688).
+- Added bts770690_java_jni_thread_detach: upstream fix for locking up the
+  Java plugin by not properly detaching from the JVM in error conditions;
+  thanks to Marc Fournier for reporting this (Closes: #770690).
+- Added bts770693_timestamps: upstream fix for handling internal
+  timestamps; thanks to Marc Fournier for reporting this (Closes: #770693)
+- Added bts770694_loglevel: upstream fix to correct logging behavior when
+  using an invalid log level; thanks to Marc Fournier for reporting this
+  (Closes: #770694, #687067).
+
+ -- Sebastian Harl tok...@debian.org  Sun, 23 Nov 2014 15:27:15 +0100
+
 collectd (5.4.1-5) unstable; urgency=medium
 
   * debian/rules:
diff -u collectd-5.4.1/debian/patches/00list 
collectd-5.4.1/debian/patches/00list
--- collectd-5.4.1/debian/patches/00list
+++ collectd-5.4.1/debian/patches/00list
@@ -6,0 +7,8

Bug#770719: unblock: collectd/5.4.1-6

[Sebastian Harl]

tags 770719 - moreinfo

On Sun, Nov 23, 2014 at 03:50:41PM +, Adam D. Barratt wrote:
 Control: tags -1 + confirmed moreinfo
 
 On Sun, 2014-11-23 at 16:32 +0100, Sebastian Harl wrote:
  This is a request for a pre-approval. The package has not been uploaded
  to unstable yet. The new version fixes various important bugs causing
  segfaults or lockups in either collectd or related software. All patches
  are already applied upstream and will be part of the next upstream patch
  release (which didn't come out in time for the freeze, thus I extracted
  all important fixes). Here's a summary of the changes; a full debdiff is
  attached:
 
 Mmm that's a lot. :-(
 
 Please go ahead, and remove the moreinfo tag once the package is in
 unstable.

Just landed in unstable a minute ago.

Thanks!

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x2F1FFCC7 +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#770593: unblock: tig/2.0.2-2

[Sebastian Harl]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package tig

The new revision fixes the important bug #757692 (display regression
since 1.2.1-1) by applying an upstream patch:

  tig (2.0.2-2) unstable; urgency=medium
  
* debian/patches:
  - Added bts757692-topo-order: upstream patch fixing a display regression;
thanks to Simon Paillard for reporting this and Jonas Fonseca for a
quick handling of the bug (Closes: #757692).
  
   -- Sebastian Harl tok...@debian.org  Sat, 22 Nov 2014 12:56:28 +0100

Debdiff attached.

unblock tig/2.0.2-2

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x2F1FFCC7 +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin

diff -Nru tig-2.0.2/debian/changelog tig-2.0.2/debian/changelog
--- tig-2.0.2/debian/changelog  2014-07-23 10:47:28.0 +0200
+++ tig-2.0.2/debian/changelog  2014-11-22 12:37:04.0 +0100
@@ -1,3 +1,12 @@
+tig (2.0.2-2) UNRELEASED; urgency=medium
+
+  * debian/patches:
+- Added bts757692-topo-order: upstream patch fixing a display regression;
+  thanks to Simon Paillard for reporting this and Jonas Fonseca for a
+  quick handling of the bug (Closes:  #757692).
+
+ -- Sebastian Harl tok...@debian.org  Sat, 22 Nov 2014 12:34:36 +0100
+
 tig (2.0.2-1) unstable; urgency=medium
 
   [ Sebastian Harl ]
diff -Nru tig-2.0.2/debian/patches/bts757692-topo-order 
tig-2.0.2/debian/patches/bts757692-topo-order
--- tig-2.0.2/debian/patches/bts757692-topo-order   1970-01-01 
01:00:00.0 +0100
+++ tig-2.0.2/debian/patches/bts757692-topo-order   2014-11-22 
12:45:35.0 +0100
@@ -0,0 +1,111 @@
+commit adb362bd657cc474629557310dfab12051bb61ac
+Author: Jonas Fonseca jonas.fons...@gmail.com
+Date:   Wed Aug 13 23:43:15 2014 -0400
+
+Force --topo-order when graph is enabled and no commit order is set
+
+This is what `git log --graph` does to ensure that parent commits comes
+before child commits. The test case is based on the example provided
+by Benjamin Bergman in issue #238.
+
+Fixes #238 and Debian bug #757692
+References #300
+
+diff a/doc/tigrc.5.adoc b/doc/tigrc.5.adoc
+--- a/doc/tigrc.5.adoc
 b/doc/tigrc.5.adoc
+@@ -234,6 +234,8 @@
+   Commit ordering using the default (chronological reverse) order,
+   topological order, date order or reverse order. The default order is
+   used when the option is set to false, and topo order when set to true.
++  Note that topological order is automatically used in the main view when
++  the commit graph is enabled and the commit order is set to the default.
+ 
+ 'ignore-case' (bool)::
+ 
+--- a/include/tig/options.h
 b/include/tig/options.h
+@@ -167,6 +167,7 @@
+ 
+ const char *ignore_space_arg();
+ const char *commit_order_arg();
++const char *commit_order_arg_with_graph(bool with_graph);
+ const char *diff_context_arg();
+ const char *show_notes_arg();
+ 
+--- a/src/main.c
 b/src/main.c
+@@ -181,33 +181,43 @@
+   return with_reflog;
+ }
+ 
++main_with_graph(struct view *view, enum open_flags flags)
++{
++  struct view_column *column = get_view_column(view, 
VIEW_COLUMN_COMMIT_TITLE);
++
++  if (open_in_pager_mode(flags))
++  return FALSE;
++
++  return column  column-opt.commit_title.graph 
++ opt_commit_order != COMMIT_ORDER_REVERSE;
++}
++
+ static bool
+ main_open(struct view *view, enum open_flags flags)
+ {
++  bool with_graph = main_with_graph(view, flags);
+   const char *pretty_custom_argv[] = {
+-  GIT_MAIN_LOG_CUSTOM(encoding_arg, commit_order_arg(), 
%(cmdlineargs), %(revargs), %(fileargs))
++  GIT_MAIN_LOG_CUSTOM(encoding_arg, 
commit_order_arg_with_graph(with_graph),
++  %(cmdlineargs), %(revargs), %(fileargs))
+   };
+   const char *pretty_raw_argv[] = {
+-  GIT_MAIN_LOG_RAW(encoding_arg, commit_order_arg(), 
%(cmdlineargs), %(revargs), %(fileargs))
++  GIT_MAIN_LOG_RAW(encoding_arg, 
commit_order_arg_with_graph(with_graph),
++  %(cmdlineargs), %(revargs), %(fileargs))
+   };
+   struct main_state *state = view-private;
+   const char **main_argv = pretty_custom_argv;
+-  struct view_column *column;
+   enum watch_trigger changes_triggers = WATCH_NONE;
+ 
+   if (opt_show_changes  repo.is_inside_work_tree)
+   changes_triggers |= WATCH_INDEX;
+ 
+-  column = get_view_column(view, VIEW_COLUMN_COMMIT_TITLE);
+-  state-with_graph = column  column-opt.commit_title.graph 
+-  opt_commit_order != COMMIT_ORDER_REVERSE;
++  state-with_graph = with_graph;
+ 
+   if (opt_rev_argv  main_check_argv(view, opt_rev_argv))
+   main_argv = pretty_raw_argv;
+ 
+   if (open_in_pager_mode(flags

Bug#764130: libdbi1: double-free in dbi_shutdown_r

[Sebastian Harl]

Package: libdbi1
Version: 0.9.0-3
Severity: serious
Tags: upstream

Hi,

I'm seeing a double-free in dbi_shutdown_r which happens after a
connection attempt (using dbi_conn_connect) fails and dbi_conn_close was
called. I don't have a full reproduction case yet but I think this is
related to the fix for #745980. I *assume* that the following happens:

 - dbi_conn_open adds the new connection to an internal list (using
   _update_internal_conn_list)

 - dbi_conn_connect does not touch that list

 - when calling dbi_conn_close after connect failed (supposedly
   conn-connection == NULL), the connection is not removed since
   dbi_conn_close returns early but after freeing the connection object
   (_update_internal_conn_list would only happen when not returning
   early)

 - when calling dbi_shutdown_r, the connection is still in the internal
   list and another attempt to close the connection is done causing an
   invalid read and the double-free

I think the right fix is to not return early at all in dbi_conn_close
but instead guard each single operation by checking if the required
fields are set (similar to how it's done in most cases already).

Let me know if you need any other information -- I can then try to come
up with a small test-case which reproduces the problem.

TIA,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#763098: libpq-dev: pg_config_manual.h redefines CACHE_LINE_SIZE

[Sebastian Harl]

Package: libpq-dev
Version: CACHE_LINE_SIZE
Severity: normal

Hi,

pg_config_manual.h redfines CACHE_LINE_SIZE in sys/param.h on kfreebsd:

  /usr/include/postgresql/pg_config_manual.h:219:0: error: CACHE_LINE_SIZE 
redefined [-Werror]
   #define CACHE_LINE_SIZE  128
   ^
  In file included from /usr/include/machine/param.h:8:0,
   from /usr/include/sys/kglue/sys/param.h:143,
   from /usr/include/sys/kern/param.h:1,
   from /usr/include/osreldate.h:1,
   from /usr/include/x86_64-kfreebsd-gnu/bits/param.h:36,
   from /usr/include/x86_64-kfreebsd-gnu/sys/param.h:31,
   from collectd.h:214,
   from postgresql.c:39:
  /usr/include/machine-amd64/param.h:97:0: note: this is the location of the 
previous definition
   #define CACHE_LINE_SIZE  (1  CACHE_LINE_SHIFT)
   ^

This causes build-errors when using -Werror. I assume that this is a
rather unusual use-case, thus didn't mark this RC.

Currently, it causes FTBFSs for collectd on kfreebsd-*, see e.g.
https://buildd.debian.org/status/fetch.php?pkg=collectdarch=kfreebsd-amd64ver=5.4.1-3.1stamp=1408492216
I hope, I'll be able to work around it using -Wp,-w there.

Cheers,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#746560: please package tig 2.0.1

[Sebastian Harl]

Hi,

On Fri, May 30, 2014 at 02:40:21PM +1000, Trent W. Buck wrote:
 Aníbal Monsalve Salazar wrote:
  Please package tig 2.0.1 available at:
  http://jonas.nitro.dk/tig/releases/tig-2.0.1.tar.gz
 
 I've done the first pass at packaging tig 2.
 I haven't updated debian/copyright,
 but I did the other things I usually do.

Thanks for you work. I've merged some of those changes into my tree.

 Lintian is happy except for
 
   P: tig source: debian-watch-may-check-gpg-signature
   P: tig: no-upstream-changelog
   W: tig: manpage-has-errors-from-man usr/share/man/man7/tigmanual.7.gz 1015: 
 warning [p 7, 10.8i, div `3tbd7,1', 0.3i]: can't break line
 
 I made a couple of contentious changes out of personal preference:
 
   - I stopped shipping HTML/PDF, since the manpages have the same content.

I did not merge that. For manuals, some people (including myself every
once in a while) prefer HTML docs.

   - I moved tigrc from /etc/ to /usr/share/doc/tig/examples,
 since the default config is also built into the binary.

I included upstream's /etc/tigrc in the package. I think it's a better
user-experience to have a config file with all the defaults which is
easy to modify rather than having the defaults (only) compiled in or in
some examples directory that you'd have to stumble across first.

The 2.0.2-1 package was uploaded a minute ago.

Cheers,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#745980: libdbi1: Memory leak in dbi_conn_close

[Sebastian Harl]

Hi,

On Mon, Apr 28, 2014 at 12:56:51PM +0200, Markus Hoenicka wrote:
 Am 2014-04-28 09:30, schrieb László Böszörményi:
 On Sun, Apr 27, 2014 at 5:41 PM, Markus Hoenicka
 markus.hoeni...@mhoenicka.de wrote:
 Package: libdbi1
 Version: 0.9.0-2
 Severity: important
 Tags: upstream
 
 That is, the memory behind 'conn' is leaked if the object was not
 connected. This happens, for example, if connecting to the DB fails.
 
 Thanks for the report and the explanation. Fixed upstream.
  How severe is it? Should I get it to the Debian package or any plan
 for a new release?
 
 Cheers,
 Laszlo/GCS
 
 Depends on usage. If you use SQLite as a backend, then you'll hardly
 ever see failing connection attempts (unless your HD is full, but
 then you're in trouble anyway). If you use something like MySQL
 running on a remote server with occasional network glitches, lost
 memory may pile up. How severe that is depends on how your
 application is written. If it is a forking server that dies once it
 is done with a connection, it probably won't hurt. If it is a
 non-forking program running 24/7, it will matter eventually.

It also depends on whether the application reuses the dbi_conn object
upon failure and simply tries to reconnect or whether it destroys the
existing object and then starts over with dbi_conn_open. Only in the
latter case, the memory (~ 100-200 bytes iIrc) will be lost.

I think it's fine to wait for a new upstream release.

Cheers,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#745892: varnish: Outdated upstream changelog in /u/s/doc

[Sebastian Harl]

Package: varnish
Version: 4.0.0-1
Severity: minor

Hi,

the upstream changelog shipped in /usr/share/doc/ states:

  Please note that this file is no longer maintained.  Please refer to the
  changes files in doc/

Please ship an up-to-date changelog instead.

Thanks,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#745902: libvarnishapi-dev: 'struct VSC_C_main' not defined

[Sebastian Harl]

Package: libvarnishapi-dev
Version: 4.0.0-1
Severity: serious

Hi,

/usr/include/varnish/vapi/vsc.h includes the following function:

  struct VSC_C_main *VSC_Main(const struct VSM_data *vd,
  struct VSM_fantom *fantom);

struct VSC_C_main is not defined in any of the headers shipped in
/usr/include/. Instead, it is defined in
/usr/share/varnish/include/common/common.h.

I'm not sure what the files in /usr/share/varnish/include/ are supposed
to be used for but they are fairly unusable. For example, common.h
includes /usr/share/varnish/include/vas.h which unconditionally defines
assert(), thus conflicting with /usr/include/assert.h. Also, the files
in /usr/share/ redefine various things which are also defined in headers
in /usr/include/, for example:

  In file included from /usr/share/varnish/include/common/common.h:42:0,
   from varnish.c:35:
  /usr/include/varnish/vapi/vsc_int.h:34:6: error: nested redefinition of 'enum 
VSC_level_e'
   enum VSC_level_e {
^
  /usr/include/varnish/vapi/vsc_int.h:34:6: error: redeclaration of 'enum 
VSC_level_e'
  In file included from /usr/include/varnish/vapi/vsc.h:38:0,
   from varnish.c:32:
  /usr/include/varnish/vapi/vsc_int.h:34:6: note: originally defined here
   enum VSC_level_e {
^

That's the point where I stopped trying to migrate code in collectd to
varnish 4.

I think it's fine to have the code in /usr/share/ conflict with
/usr/include/. After all, /usr/share/ seems to be used for Varnish
modules only. However, /usr/include/ needs to be self-containing.

Thanks,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#731328: [mon] patch for dns.monitor

[Sebastian Harl]

reassign 731328 mon 1.2.0-6
thanks

On Wed, Dec 04, 2013 at 12:00:42PM +0100, Brogniaux Gaëtan wrote:
 Package: collectd

dns.monitor is shipped by mon instead of collectd. Reassigning the bug
with this email.

 Version: 1.2.0-6
 
 When I use dns.monitor, I've got Perl problem when calling normally or
 simple with --help argument :
 # /usr/lib/mon/mon.d/dns.monitor 127.0.0.1
 defined(@array) is deprecated at /usr/lib/mon/mon.d/dnscustom.monitor
 line 171.
(Maybe you should just omit the defined()?)
 defined(@array) is deprecated at /usr/lib/mon/mon.d/dnscustom.monitor
 line 176.
(Maybe you should just omit the defined()?)
 defined(@array) is deprecated at /usr/lib/mon/mon.d/dnscustom.monitor
 line 182.
(Maybe you should just omit the defined()?)
 
 The defined function in recent perl is deprecated and genere a mon alerte.
 See this great information at :
 http://blogs.perl.org/users/rurban/2012/02/on-definedarray-and-definedhash.html
 
 This is my patch works well : diff /usr/lib/mon/mon.d/dns.monitor
 /usr/lib/mon/mon.d/dnscustom.monitor
 171c171
  if (!defined(@Master)) {
 ---
  if (! @Master) {
 176c176
  if ( !defined(@Zones) ) {
 ---
  if (! @Zones) {
 182c182
  if ( !defined(@Queries) ) {
 ---
  if (! @Queries) { 
 
 I am using Linux antispam 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64
 GNU/Linux
 libc6:amd64 2.13-38
 perl 5.14.2-21+deb7u1
 
 -- 
 Brogniaux Gaëtan
 Tel direct  : 065/842.385 (ext 6018)
 Tel support : 065/328.585
 
 IT-Optics s.a.
 Boulevard Initialis, 28
 7000 Mons
 Belgium
 TVA: BE473274282 /  RC: MONS 143271

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#743881: collectd: collection.cgi don't graph apache stats

[Sebastian Harl]

tags 743881 + fixed-upstream
thanks

Hi,

On Mon, Apr 07, 2014 at 05:19:34PM -0300, Fabiano Pires wrote:
 When I tried to graph apache2 stats with collectd/collection.cgi, I got these 
 results:
 * No graph is generated for this plugin (others plugins are graphing ok).
 * Apache have mod_status enabled and configured (I can access it via brwoser 
 and wget).
 * Apache's log contains some lines like this:
   collection.cgi: RRDs::graph: No DS called 'count' in 
 '/var/lib/collectd/rrd/jb1.example.org/apache-raiz/apache_bytes.rrd' at 
 /usr/lib/cgi-bin/collection.cgi line 787
 
 After some googling, I found somewhere that the DS name in the rrd files 
 changed from 'count' to 'value'.
 So I opened collection.cgi in vim and did :960,1021s/count/value. This 
 solved the issue.

Thanks you for reporting this and providing a patch!

I've submitted your fix to the upstream repository:
https://github.com/collectd/collectd/commit/5d0a10f15f361c6f019b48d0619e87ee8bb936e3

It'll be included in the next upstream release.

Cheers,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#739625: collectd: df plugin not working since wheezy

[Sebastian Harl]

retitle 739625 collectd: collection.cgi does not support df plugin
tags 739625 + fixed-upstream
thanks

On Thu, Feb 20, 2014 at 12:32:11PM -0300, Joel Franco Guzmán wrote:
 Since Wheezy i can't run the df plugin in collection.cgi.
 
 I install the collection.cgi since squeeze running:
 
   # apt-get install collectd libhtml-parser-perl librrds-perl apache2
   # cp /usr/share/doc/collectd/examples/collection.cgi /usr/lib/cgi-bin/

Side-note: collection.cgi is just an example and somewhat outdated in
general. collection3 (also included in /u/s/d/collectd/examples/) is
generally preferred nowadays.

 I have read in web about exclude some types of filesystems. That solved
 the log problem (another problem) but not the graphic generation.

Note that the new default configuration shipped with the latest versions
of collectd in Debian exclude a bunch of filesystems by default.

 I can see the graphs borders, but not the graphics itself.

The problem is that the df plugin changed from data-type 'df' to
'df_complex' in collectd 5.x and collection.cgi was not updated in that
respect. I've pushed a patch upstream to fix this:
https://github.com/collectd/collectd/commit/25831ec7b1d3d36a7f2dac2baf9a47c8099deba4

You should be able to simply apply this patch to your local version of
collection.cgi. Also, it will be included in the next upstream release
but I won't push the fix to Wheezy.

Cheers,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#745980: libdbi1: Memory leak in dbi_conn_close

[Sebastian Harl]

Package: libdbi1
Version: 0.9.0-2
Severity: important
Tags: upstream

Hi,

in dbi_conn_close:

  if (!conn || !(conn-connection)) return;
  …
  free(conn);

That is, the memory behind 'conn' is leaked if the object was not
connected. This happens, for example, if connecting to the DB fails.

Cheers,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#419948: librrds-perl: Information about affected platform

[Sebastian Harl]

tags 419948 + wontfix
thanks

This bug had not seen any activity in year. It seems rather unlikely
that any resources will be spent on this and further tracking it does
not make sense imho.

Also note that there are some ideas around redesigning RRDtool from the
ground up -- see https://github.com/oetiker/rrdtool-2.x

On Sun, Mar 21, 2010 at 05:17:16PM +0100, Sebastian Harl wrote:
 Hi Florian and Carl,
 
 (This is a follow-up to Debian bug report #419948 -- see
 http://bugs.debian.org/419948 for details.)
 
 On Wed, Sep 30, 2009 at 09:54:06PM +0200, Sebastian Harl wrote:
  On Mon, Sep 28, 2009 at 10:32:52AM +0200, Florian Schlichting wrote:
   On Thu, Sep 24, 2009 at 06:17:55PM +0200, Sebastian Harl wrote:
Okay, so it seems we've got a rather major speed-down in rrdgraph Sarge
- Etch (RRDtool 1.0 - 1.2) and another one Etch - Lenny (RRDtool 1.2 
-
1.3). In the former case, RRDtool switched from using libgd to libart
for doing the graphing, in the latter case, they switched to libcairo
(and libpango). I'm pretty sure, the speed-down is related to that. In
the course of the 1.3.x releases some optimizations have been applied
which improved the effect a bit but there still is a notable speed-down.

Anyway, frankly, I've got no idea what to do about that. 
   
   well, I think that's a good explanation. So it's not a bug, but an
   intentional design decision with not-so-intentional side effects.
 […]
   I don't know about upstream's motivation for those switches, but
   perhaps it would be worthwhile to benchmark graphing with the
   different libraries / RRDtool versions and reevaluate their merits in
   that light?
  
  I'm not sure about the motivations either :-/ Benchmarks would be really
  great. Are you willing to take care of that?
 
 Does anyone of you happen to have some benchmarks available (or could
 you rather easily get any)?
 
 With this E-mail, I'm also forwarding the bug upstream (this should have
 happened long ago :-/ ), hoping for some more input / suggestions /
 further ideas.
 
 Cheers,
 Sebastian
 

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#499305: 1.2.6/on lenny

[Sebastian Harl]

tags 499305 + moreinfo
thanks

Hi,

On Tue, Oct 07, 2008 at 07:18:13PM +0200, Arno Bottema wrote:
 All hosts (except one that will be Etch soon) are Etch. The newly
 added host is also Etch.

There were a lot of fixes in RRDtool since Etch, fixing a few segfaults
and memory holes. Does this problem still exist?

Thanks,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#606844: rrdcached: default UNIX socket permision should be changed.

[Sebastian Harl]

forwarded 606844 rrd-develop...@lists.oetiker.ch
thanks

Hi,

On Sun, Dec 12, 2010 at 11:14:58AM +0100, Witold Baryluk wrote:
 Strange, but
 when I start rrdcached with default debian options, i have
 
 # ls -l /var/run/rrdcached.sock  -l
 srwxr-xr-x 1 root root 0 12-12 10:51 /var/run/rrdcached.sock
 #
 
 but when I add -s adm at th begining of options, i have
 
 # ls -l /var/run/rrdcached.sock  -l
 srwxrw 1 root adm 0 12-12 10:52 /var/run/rrdcached.sock
 #
 
 Shouldn't socket also in default mode also use 760 or 770 ?
 Isn't default  mode somehow unsecure *755 !?

Yeah, this should be more consistent. Anyway, a few things to note:

 - changing the behavior would be a backward incompatible change

 - some operating systems don't care about file permissions of a UNIX
   socket (however, Linux does take them into account)

 - I'm not sure what the best behavior would be; I don't consider 755
   insecure for most use-cases, so that could still be a good default

Anyway, once a solution has been agreed upon, a fix will be easy.
Currently, rrdcached calls chmod only if -s was specified on the command
line:

  chmod(path, (S_IRUSR|S_IWUSR|S_IXUSR | S_IRGRP|S_IWGRP)

That is, by default, you get permissions based on your umask and 770
else.

Forwarding this upstream for further input.

Cheers,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#661211: librrd4 huge dependency bloat (20+ MB)

[Sebastian Harl]

Hi,

sorry for the huge delay :-/

On Sat, Feb 25, 2012 at 02:31:11AM +0100, Jakob Bohm wrote:
 The librrd4 package seems (from the outside) to consist of two very
 different parts:
[…]
 Unfortunately, the two parts are currently packaged together with
 the result that simply installing sensord to get hardware
 monitoring events (such as CPU temperature) logged to the system
 logs forces the installation of slightly more than 20MB of GUI
 dependencies even on a completely headless semi-embedded system.
 These dependencies (direct and indirect) include such large items
 as the Cairo 2D library, the Pango East-Asian font library and the
 Defoma font management system, none of which serve any purpose
 when just logging the system health on a slow embedded system.

This has come up several times in the past and various approaches were
discussed. If you dig through the rrdtool-developers mailinglist, you'll
find some discussions around this.

Unfortunately, nobody has stepped up so far to actually implement any of
that.

 I suggest splitting the librrd shared library package into two
 library packages: librrdN for the basic data storage code needed
 by system software such as sensord, and librrd-guiN for the
 additional GUI functions needed mostly by closely related packages
 such as some other packages built from the rrdtool source package.

Please note that there's some discussion around rewriting RRDtool from
the ground up. This is currently tracked as rrdtool-2 on Github. This
specific issue is tracked as
https://github.com/oetiker/rrdtool-2.x/issues/33

Cheers,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#691765: Bindings don't seem to release the GIL when doing I/O

[Sebastian Harl]

forwarded 691765 rrd-develop...@lists.oetiker.ch
thanks

Hi,

On Mon, Oct 29, 2012 at 02:49:03PM +0100, Enrico Zini wrote:
 I was auditing the rrdtool binding code to check if they could be used
 in a python thread without locking the entire application via the GIL.
 
 Extensions are supposed to release the GIL lock around potentially
 blocking I/O operations like reading or writing a file, so that other
 Python threads can run in the meantime.
 
 I went through rrdtoolmodule.c and didn't see any use of
 Py_BEGIN_ALLOW_THREADS or thread-related functions, so it looks like
 python-rrdtool would keep all concurrent threads of the application
 blocked during I/O.
 
 http://docs.python.org/2/c-api/init.html#threads has more details.
 
 This isn't an urgent issue for me personally: we're using pyrrd
 through the 'external' backend, which uses Popen to invoke rrdtool, and
 Popen correctly releases the GIL during I/O. However, I felt like I
 should share what I found during my little code review.

Thanks for sharing this. With this email, I'm forwarding the issue to
the upstream developers mailinglist for further attention.

Cheers,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#603507: rrdupdate: manpage contains twice When using negative time values, ...

[Sebastian Harl]

forwarded 603507 https://github.com/oetiker/rrdtool-1.x/pull/459
thanks

Hi,

On Sun, Nov 14, 2010 at 09:01:24PM +0100, Sandro Tosi wrote:
 the manpage for rrdupdate contains twice this paragraph (under the section for
 'N|timestamp:value[:value...]')
 
   When using negative time values, options and data have to be separated by 
 two
   dashes (--), else the time value would be parsed as an option.  See below 
 for
   an example.

Thanks for reporting this! I've opened a pull request for upstream.

Cheers,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#734788: collectd: Too many dependencies

[Sebastian Harl]

Hi,

On Mon, Jan 13, 2014 at 04:19:59AM +0400, Andrey wrote:
  Recommends / Suggests only includes dependencies of actual plugins.
 
 C'mon, it's about 200 Mbytes of unneeded libraries, like tokyotyrant or
 varnish, or libvirt etc, not counting full jdk installation and others,
 which most users won't need.

So, the problem is that I don't have any numbers about which plugins are
used most. I would like to avoid (unless there's a really good reason
for it) to handle some plugins differently from the rest because that
creates an inconsistent experience. The user would then have to know
whether or not a plugin has external dependencies and whether those
dependencies are usual or not. So for, nobody (including myself) had a
real answer to that.

 I'm trying to use collectd in virtual
 environment with puppet system rollout which means that each virtual
 machines downloads 200 Mbytes on start. If you build it manually, at least
 you have an option to not to include unneeded plugins. This package forces
 user to install them. Check other big packages like php or python. They are
 broken into many pieces so I can install only needed ones.

The packages do not force the installation of any of the dependencies.
That's why there is collectd-core and collectd which provide different
degrees of flexibility by suggesting or recommending all plugin
dependencies.

The solution I have in mind for cases like yours is to either disable
installation of recommended packages and then use the collectd package
or to build your own meta-package which provides your custom
configuration, the required dependencies for that configuration and then
depends on collectd-core.

HTH,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#734788: collectd: Too many dependencies

[Sebastian Harl]

Hi,

On Mon, Jan 13, 2014 at 07:14:19PM +0400, Andrey wrote:
  So, the problem is that I don't have any numbers about which plugins are 
  used most. 
  I would like to avoid (unless there's a really good reason for it) to 
  handle some plugins 
  differently from the rest because that creates an inconsistent experience.
 
 My suggestion here is to have separate collectd-core package with just core
 application and docs and several collectd-plugin-* (like
 collectd-plugin-disk) packages with just .so file and, if applicable,
 default config file in /etc/collectd/plugins.d subdir or something like
 that.

Having one package for each plugin would mean about 100 plugin-*
packages. I don't think that this is user-friendly.

I was already thinking about having a couple of packages for some groups
of plugins. However, I could not come up with any reasonable grouping.
That would have to take functional similarity and dependencies into
account in order to be useful. Getting that right would be complicated
and getting it not quite right would be heavily confusing imho.

I've already discussed this issue a couple of times with different
people. In all cases, the end result was that the current approach is
the best after all.

 Metapackage might install something that already enabled by default,
 like rrd, network etc, or might not install anything at all, allowing user
 to decide which ones to use. 

I've had a couple of thoughts into that direction as well. However, all
ideas I've had so far basically boil down to the same problems I've
already discussed.

  The packages do not force the installation of any of the dependencies.
  That's why there is collectd-core and collectd which provide different
  degrees of flexibility by suggesting or recommending all plugin
  dependencies.
 
 Oh, I never tried to install just collectd-core, always thought I should use
 collectd package.

The collectd package is meant to be used by people who do not want to
think about how to setup collectd. By default, by using Recommends for
all dependencies, it simply works. However, it still allows to adjust
the setup and, for example, remove stuff that you don't want.

collectd-core is meant to be used by advanced users and as a base for
custom packaging (configuration).

  build your own meta-package which provides your custom configuration, the
  required dependencies for that configuration and then depends on
  collectd-core.
 
 Currently, I end up with manual rebuilding the package, adding several
 --disable-plugin options to configure. At this point I've decided to create
 this thread.

I don't think this is necessary, since you can easily remove any
dependency you don't need.

HTH,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#730397: Please switch build-dependency from libupsclient1-dev to libupsclient-dev

[Sebastian Harl]

tags 730397 + pending
thanks

On Sun, Nov 24, 2013 at 06:43:44PM +0100, Laurent Bigonville wrote:
 I'm planning to upload nut 2.7.1 soon. 
 
 The libupsclient library has a new soname and this will require to
 rebuild collectd, I've also renamed the libupsclient1-dev package to
 libupsclient-dev.
 
 Please adjust the build-dependency when the new nut version has hit the
 archive.

I've switched to libupsclient1-dev | libupsclient-dev. The fix is in
http://git.tokkee.org/?p=pkg-collectd.git;h=c58bb5a (and the two parent
commits).

Upload pending a fix for #731156.

Thanks,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#734788: collectd: Too many dependencies

[Sebastian Harl]

tags 734788 + wontfix
thanks

Hi,

On Fri, Jan 10, 2014 at 12:46:52AM +0400, Andrey wrote:
  Did you read /usr/share/doc/collectd-core/README.Debian.plugins ?
 
  I personally disagree with this suggestion, as they already aren't hard
  dependencies, merely suggestions/recommendations.
 
  If you need to setup stripped-down systems, it's in any case a good habit
  to disable installation of 
  suggestions/recommendations, regardless of whether collectd is installed
  or not:
 
  APT::Install-Recommends 0;
  APT::Install-Suggests 0;
 
  Just my 2c...
 
 Yes, I've read it. Actual plugins (.so modules) have these dependencies, and
 not installing them might cause broken software if I would try to load them
 anytime later. 

Recommends / Suggests only includes dependencies of actual plugins.

This topic is coming up every once in a while but I believe that the
current situation is the best we can have. Splitting the package into a
lot of sub-packages is something Debian FTPmasters would not like to see
and also it would not be nice to handle for users. Both approaches have
their pros and cons, after all.

I'm tagging this wontfix to keep the bug around for future reference. If
anyone has further suggestions on how to improve the packaging, I'd
appreciate further comments and discussions.

Thanks,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#732701: collectd segfaulted when curl plugin used

[Sebastian Harl]

tags 732701 +fixed-upstream
thanks

Hi,

On Fri, Dec 20, 2013 at 05:19:40PM +0400, Alexander Golovko wrote:
 collectd crash, when curl plugin used.

Thanks for reporting this! I could reproduce the bug with your config
and push a fix upstream:
https://github.com/collectd/collectd/commit/8e9bdd5a63e67c6adb403c2aac4a25e0595ea147

I'll fix the Debian package in the next upload, either by pulling in
that patch or using a new upstream release.

 LoadPlugin curl
 Plugin curl
   Page test
   URL http://example.com;
   Match
   Regex test: (\d+)

You should use \\d instead of \d. The config parser uses a backslash
to escape characters and, thus, requires a verbatim backslash to be
escaped.

   DSType DeriveSet
   Type test
   /Match
   /Page
 /Plugin

Cheers,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#726921: iproute2: Please reintroduce iproute(2)-dev package for netlink library

[Sebastian Harl]

retitle 726921 collectd: build-depends on removed iproute-dev unnecessarily
thanks

Hi,

On Sun, Oct 20, 2013 at 08:50:33PM +0200, Andreas Henriksson wrote:
 Making sure iproute-dev didn't have any reverse (build-)dependencies
 before dropping it was a mistake. Fortunately only collectd
 was affected and has been fixed upstream to use libmnl instead
 (and AFAIK it should have reached Debian now as well?!).
 This has the additional affect that collectd can enable the
 netlink plugin on more then i386.

Whoops … I've switched the package to libmnl in 5.4.0-1 but forgot to
remove the build-dep on iproute-dev.

 I don't intend to reintroduce the quite useless iproute-dev package
 so I'm reassigning to collectd which should drop any leftover
 iproute-dev build-dependency if it still exists.

Thanks! I'll remove the left-over cruft.

Cheers,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#710658: collectd: df plugin causes lots of syslog messages: Illegal attempt to update

[Sebastian Harl]

Martin Steigerwald mar...@lichtvoll.de wrote:
The df plugin is producing lots of log messages like even after fresh
install on two VMware ESX hosted virtual machines:

Jun  1 12:17:53 somehost collectd[29921]: Initialization complete,
entering read-loop.
Jun  1 12:17:53 somehost collectd[29921]: battery plugin: Failed to
access `/proc/acpi/battery': No such file or directory
Jun  1 12:17:53 somehost collectd[29921]: rrdtool plugin: Adjusting
RandomTimeout to 0.000 seconds.
Jun  1 12:17:53 somehost collectd[29921]: rrdtool plugin: rrd_update_r
(/var/lib/collectd/rrd/somehost/df-root/df_complex-free.rrd) failed:
/var/lib/collectd/rrd/somehost/df-root/df_complex-free.rrd: illegal
attempt to update using time 1370081873 when last update time is
1370081873 (minimum one second step)
[...]
To do a clear reproducer I have re-installed collectd from scratch with
clean configuration. On using reportbug I found bug #657122, but these
messages also appear when I apply the suggested configuration change:

Does this continue to happen after the first iteration? There is/was a
bug that caused read callbacks to be executed twice upon startup.

On a related note: this message keeps making trouble and should
really be turned into a complaint.

Cheers,
Sebastian

Hi Martin,

-- 
Sent from my phone. Please excuse my brevity.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#710658: collectd: df plugin causes lots of syslog messages: Illegal attempt to update

[Sebastian Harl]

Martin Steigerwald mar...@lichtvoll.de wrote:

Am Samstag, 1. Juni 2013, 14:46:00 schrieb Sebastian Harl:
 Martin Steigerwald mar...@lichtvoll.de wrote:
 The df plugin is producing lots of log messages like even after
fresh
 install on two VMware ESX hosted virtual machines:
 
 Jun  1 12:17:53 somehost collectd[29921]: Initialization complete,
 entering read-loop.
 Jun  1 12:17:53 somehost collectd[29921]: battery plugin: Failed to
 access `/proc/acpi/battery': No such file or directory
 Jun  1 12:17:53 somehost collectd[29921]: rrdtool plugin: Adjusting
 RandomTimeout to 0.000 seconds.
 Jun  1 12:17:53 somehost collectd[29921]: rrdtool plugin:
rrd_update_r
 (/var/lib/collectd/rrd/somehost/df-root/df_complex-free.rrd) failed:
 /var/lib/collectd/rrd/somehost/df-root/df_complex-free.rrd: illegal
 attempt to update using time 1370081873 when last update time is
 1370081873 (minimum one second step)
 
 [...]
 
 To do a clear reproducer I have re-installed collectd from scratch
with
 clean configuration. On using reportbug I found bug #657122, but
these
 
 messages also appear when I apply the suggested configuration
change:
 Does this continue to happen after the first iteration? There is/was
a
 bug that caused read callbacks to be executed twice upon startup.
 
 On a related note: this message keeps making trouble and should
 really be turned into a complaint.

What do you mean by first iteration?

I had those happen on one server for long time without really noticing
it:

somehost:~ zgrep -c illegal attempt /var/log/syslog*
/var/log/syslog:6682
/var/log/syslog.1:25920
/var/log/syslog.2.gz:25920
/var/log/syslog.3.gz:25920
/var/log/syslog.4.gz:25920
/var/log/syslog.5.gz:25920
/var/log/syslog.6.gz:26129
/var/log/syslog.7.gz:25926


Earliest message I still have is:

somehost:~ zcat /var/log/syslog.7.gz | grep illegal attempt | head
-1
May 25 06:25:15 somehost collectd[2188]: rrdtool plugin: rrd_update_r 
(/var/lib/collectd/rrd/somehost/df-root/df_complex-free.rrd) failed: 
/var/lib/collectd/rrd/somehost/df-root/df_complex-free.rrd: illegal
attempt to 
update using time 1369455915 when last update time is 1369455915
(minimum one 
second step)


And it happens also after restarting collectd. Log messages appear
immediately 
and continue to appear as long as collectd is running, so far as I have

observered.

Yep, that's what I meant. I'll need to have another look at that, then.

Cheers,
Sebastian


-- 
Sent from my phone. Please excuse my brevity.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#708718: collectd: diff for NMU version 5.1.0-3.1

[Sebastian Harl]

Hi gregor,

On Sun, May 26, 2013 at 01:00:00AM +0200, gregor herrmann wrote:
 I've prepared an NMU for collectd (versioned as 5.1.0-3.1) and
 uploaded it to DELAYED/2. Please feel free to tell me if I
 should delay it longer.

Thanks for taking care of that! I was sick for the past 1.5 weeks, so
this is much appreciated. DELAYED/2 is perfectly fine for me.

Cheers,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#706139: debtree should have a --skiplist option

[Sebastian Harl]

Package: debtree
Version: 1.0.10
Severity: wishlist

Hi,

it would be nice if debtree would have a --skiplist (or --ignore or
similar) command line option, that may be used to temporarily add
certain packages to the skip-list.

Thanks,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#701912: tig: Failed to chdir: No such file or directory when used inside submodule

[Sebastian Harl]

severity 701912 important
thanks

Hi,

On Thu, Feb 28, 2013 at 05:10:57PM +, Mike Crowe wrote:
 tig reports errors like:
 
  tig: Failed to chdir(../../submodule-directory): No such file or directory
 
 when started inside a submodule that has been created by the version of git in
 Wheezy (1:1.7.10.4-1+wheezy1)
 
 It looks like this problem has been discovered and solved upstream:
 
 https://github.com/jonas/tig/issues/54

Thanks for reporting this and pointing out the fix! This should be
included in tig-1.1-1, which is currently available in experimental.
Would you mind double-checking that?

 The patch seems to be small and hopefully suitable for getting into Wheezy.

I do consider this to be an important bug and I should be able to get it
into Wheezy through unstable (unless any build-deps come into the way).
So, I hope to get the fix into Wheezy.

Cheers,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#544614: Bug fixed in squeeze

[Sebastian Harl]

Hi,

On Wed, Feb 13, 2013 at 12:21:41PM +0100, Cyril Bouthors wrote:
 This bug is no longer reproducible under squeeze.

Thanks for double-checking and reporting back!

Cheers,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#684420: [Pkg-nagios-devel] Bug#684420: pnp4nagios-bin: librrds-perl dependency may alternatively be satisfied by rrdtool

[Sebastian Harl]

tags 684420 + wontfix
thanks

Hi,

On Thu, Aug 09, 2012 at 09:44:26PM +0200, Christoph Anton Mitterer wrote:
 As far as I understand, only process_perfdata.pl uses librrds-perl, right?
 And this might also be run with the native rrdtool (by setting USE_RRDs=0).
 
 I absolutely agree that this is by itself stupid, and people should use
 the Perl modules,... but there may be guys out there who really have
 whatever reasons not to do this (though I can't imagine any).

I don't think that there would be any real reason for that. So, as long
as nobody comes up who could imagine any *real* reason for that, I won't
do that. I just don't think using the rrdtool binary rather than the
Perl module makes any sense.

 OTOH, though: /usr/lib/pnp4nagios/libexec/rrd_convert.pl seems to really
 depend on the native rrdtool.
 
 So we might want to either suggest or recommend rrdtool in addition anyway.

Yeah, that makes sense. I've added rrdtool to the suggested packages.

Cheers,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#683702: [Pkg-nagios-devel] Bug#683702: Bug#683702: pnp4nagios-web: location of the status-header.ssi

[Sebastian Harl]

tags 683702 + wontfix
thanks

Hi,

On Fri, Aug 03, 2012 at 10:36:07AM +0200, Sebastian Harl wrote:
 On Fri, Aug 03, 2012 at 01:21:18AM +0200, Christoph Anton Mitterer wrote:
  This is (if at all) just a cosmetic issue:
  Currently status-header.ssi is placed at
  /usr/share/doc/pnp4nagios/examples/ssi/status-header.ssi
  
  Now at one side this is ok,... because it's just an example
  of what can be done with the status-header feature of Nagios/icinga.
  
  On the other side... likely no one will ever modify this and use his
  own version.
  So I guess most people do about the following (using Apache and Icinga as 
  examples)
  to enable it:
  Alias /icinga-cgi-url-path/ssi/status-header.ssi 
  /usr/share/doc/pnp4nagios/examples/ssi/status-header.ssi
  
  
  Well, I can't help but that seems ugly... because status-header.ssi is 
  like executable code... and that should not be in /usr/share/doc/
  
  
  As said I'm not even sure wether this is really better/cleaner... but what 
  do you
  think about moving that into /usr/share/pnp4nagios/ssi ?
 
 Sounds ok for me. I'll look into that after Wheezy ;-)

Thinking about this again, I don't think that this makes a lot of sense.
After all, there is no such thing as SSI in PNP4Nagios. People should
rather copy the file to the appropriate location.

Cheers,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#657122: fixed in collectd 5.2.0-1

[Sebastian Harl]

Hi,

On Sun, Jan 20, 2013 at 06:18:53PM +0100, Maximilian Engelhardt wrote:
 This bug is still present in testing/unstable. Are there any plans to fix it 
 there?

I don't consider this bug to be serious, so it's no candidate for a
Freeze exception. However, you can fairly easily take of it yourself by
applying the following patch to your collectd.conf:
http://git.tokkee.org/?p=pkg-collectd.git;h=2e0ae5b

HTH,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#696142: tig 1.0 fails to build from source

[Sebastian Harl]

Hi,

On Mon, Dec 17, 2012 at 10:36:31AM +0100, Salvatore Bonaccorso wrote:
 On Mon, Dec 17, 2012 at 09:40:42AM +0100, Mathieu Malaterre wrote:
  Package: tig
  Version: 1.0-2
  Severity: serious
  Justification: fails to build from source
  
  I cannot build tig from my squeeze system it fails with:
  ^^^ tig 1.0-2 is in testing and
unstable.
 
 I tried to build both with pbuilder and sbuild, and cannot get the
 FTBFS in unstable. Thus I'm unsure about the severity, since it does
 not affect the build of the testing/unstable version in
 testing/unstable.
 
 p.s.: Just also tested, was able to build tig in a squeeze sbuild
 environment.

Salvatore, thanks for taking care of this!
Also, thanks Mathieu for re-checking and closing the bug :-)

Cheers,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#695226: [Pkg-nagios-devel] Bug#695226: Bug#695226: pnp4nagios: Upgrade fails due to changed ownership

[Sebastian Harl]

Hi,

On Thu, Dec 06, 2012 at 12:03:14PM +0100, Alma Mahler wrote:
   User/Group: icinga:icinga
  such a group doesn't exist in the icinga packages. If you changed anything
  to
  have and use this group you are on your own, such a combination is not
  supported and will probably never.
 
 thanks for the answer. It would be ok to check for the user only.
 And/or, during the upgrade, not to touch the ownership of the
 directories and files. At least to give a hint in a README or during
 installation that the ownership has to be changed.

Well, this is true for each and every file installed by a Debian
package. I don't see why we should mention that in this particular
README file.

See the documentation of dpkg-statoverride(8) for a tool that might help
you achieve what you're trying to do. However, note that you are
entirely on your own regarding that kind of setup including maintaining
it whenever any of the affected packages change.

Anyway, why did you switch from nagios:nagios to icinga:icinga in the
first place?

Cheers,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#690668: collectd: Please add /etc/collectd.d/ to easily enable plugins

[Sebastian Harl]

Hi,

On Tue, Oct 16, 2012 at 11:31:17AM +0200, Laurent Bigonville wrote:
 It could be nice if you could add a /etc/collectd.d directory where
 the user could drop config stanza to easily enable plugins.

Sounds like a good idea to me.

 Adding Include /etc/collectd.d/*.conf in collectd.conf and creating
 the directory seems to work.

Well, kind of ;-) This will report an error on startup if there is no
file matching the specified pattern. This would confuse users if it was
used in the default configuration (- everybody would get the error).

Anyway, I've created a patch adding support for recursively including
all files matching a specified pattern. In this case, no error will be
generated if there is no match. This way, I could add the following to
collectd.conf:

  Include /etc/collectd/collectd.conf.d *.conf

This would work similar to find /etc/collectd/collectd.conf.d -name
*.conf and include all files found this way.

See https://github.com/collectd/collectd/pull/205 for details.

What do you think? ;-)

Cheers,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#630682: collectd: ping plugin ignores Interval in case of warnings

[Sebastian Harl]

tags 630682 +moreinfo
thanks

Hi,

On Thu, Jun 16, 2011 at 11:29:44AM +0200, Bernd Zeimetz wrote:
 whenever the ping plugin throws a WARNING and hits 'continue' in the
 main while loop, the Interval setting will be ignored as
 pthread_cond_timedwait is only executed when the whole loop body run
 trough successful. So when things like 'ping plugin: Cannot find host'
 happen, my syslog will be spammed...

Hrm, can you provide an example for that? From looking at the code, this
should not happen because 'continue' is only used in the inner iterator
loop. The main while loop does not use 'continue' at all but only uses
'break' to shutdown the ping-thread completely.

Cheers,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#683720: unblock: rrdtool/1.4.7-2

[Sebastian Harl]

Hi,

sorry, I must have missing this E-mail somehow :-/

On Sat, Aug 04, 2012 at 04:48:02PM +0100, Adam D. Barratt wrote:
 On Fri, 2012-08-03 at 10:28 +0200, Sebastian Harl wrote:
  Please unblock package rrdtool
  
  The current version in unstable (1.4.7-2) fixes an RC bug (#664724)
  causing RRDCacheD (the RRDtool Caching Daemon) to segfault on startup if
  the daemon's data directory does not exist. This bug had been addressed
  by an NMU by creating the default directories in the init script. I've
  later added a patch fixing the issue in the daemon in order to provide a
  general fix for the underlying issue.
 
 This change appears not to be documented in the changelog:
 
 --- rrdtool-1.4.7/debian/control
 +++ rrdtool-1.4.7/debian/control
 @@ -8,7 +8,7 @@
 [...]
 - tcl-dev (= 8.5), tcl (= 8.5),
 + tcl-dev (= 8), tcl-dev (= 9),

Yes, this was a minor fix which was applied to the Debian Git tree in
between our last upload to unstable and the 1.4.7-1.1 NMU and thus kinda
accidentally ended up in the current upload.

The former restriction (depend on = 8.5) was used for a test-build
against newer versions of Tcl but is not imposed by RRDtool. Removing
that restriction does not harm building RRDtool but, in contrast, makes
backporting easier.

I'm sorry that I missed the change on the last upload but imho it's
perfectly safe to let that into Wheezy. Anyway, if you would not prefer
to let that in during the freeze, please tell me whether you prefer a
new upload to unstable reverting that or an upload to -p-u only
including the other (documented) changes.

Thanks in advance,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#683720: unblock: rrdtool/1.4.7-2

[Sebastian Harl]

Hi,

On Sat, Aug 18, 2012 at 12:10:18PM +0100, Adam D. Barratt wrote:
 On Sat, 2012-08-18 at 11:36 +0200, Sebastian Harl wrote:
  sorry, I must have missing this E-mail somehow :-/
  
  On Sat, Aug 04, 2012 at 04:48:02PM +0100, Adam D. Barratt wrote:
   This change appears not to be documented in the changelog:
   
   --- rrdtool-1.4.7/debian/control
   +++ rrdtool-1.4.7/debian/control
   @@ -8,7 +8,7 @@
   [...]
   - tcl-dev (= 8.5), tcl (= 8.5),
   + tcl-dev (= 8), tcl-dev (= 9),
  
  Yes, this was a minor fix which was applied to the Debian Git tree in
  between our last upload to unstable and the 1.4.7-1.1 NMU and thus kinda
  accidentally ended up in the current upload.
 
 Ah.
 
  The former restriction (depend on = 8.5) was used for a test-build
  against newer versions of Tcl but is not imposed by RRDtool. Removing
  that restriction does not harm building RRDtool but, in contrast, makes
  backporting easier.
 
 Thanks for the explanation.  It would be nice if the changelog could be
 fixed up for a future upload, but I've unblocked the package as-is.

Thanks! I've fixed the changelog in Git for the next upload.

Cheers,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#683720: unblock: rrdtool/1.4.7-2

[Sebastian Harl]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package rrdtool

The current version in unstable (1.4.7-2) fixes an RC bug (#664724)
causing RRDCacheD (the RRDtool Caching Daemon) to segfault on startup if
the daemon's data directory does not exist. This bug had been addressed
by an NMU by creating the default directories in the init script. I've
later added a patch fixing the issue in the daemon in order to provide a
general fix for the underlying issue.

Attached to this E-mail, you'll find a full debdiff for the source and
all binary packages.

unblock rrdtool/1.4.7-2

TIA,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin

diff -u rrdtool-1.4.7/debian/control rrdtool-1.4.7/debian/control
--- rrdtool-1.4.7/debian/control
+++ rrdtool-1.4.7/debian/control
@@ -8,7 +8,7 @@
  zlib1g-dev, libpng12-dev, libcairo2-dev, libpango1.0-dev, libfreetype6-dev,
  libdbi0-dev,
  libxml2-dev,
- tcl-dev (= 8.5), tcl (= 8.5),
+ tcl-dev (= 8), tcl-dev (= 9),
  perl (= 5.8.0),
  python-all-dev (= 2.6.6-3~), python-all-dbg (= 2.6.6-3~),
  ruby1.8, ruby1.8-dev, ruby1.9.1, ruby1.9.1-dev,
diff -u rrdtool-1.4.7/debian/rules rrdtool-1.4.7/debian/rules
--- rrdtool-1.4.7/debian/rules
+++ rrdtool-1.4.7/debian/rules
@@ -123,7 +123,7 @@
 
 	# clean what the Makefiles do not clean ...
 	rm -rf bindings/perl-piped/blib bindings/perl-shared/blib \
-	   bindings/perl-piped/Makefile.old bindings/perl-shared/Makefile.old
+	   bindings/perl-piped/Makefile.old bindings/perl-shared/Makefile.old bindings/perl-shared/MYMETA.yml
 	rm -f bindings/tcl/pkgIndex.tcl bindings/tcl/tclrrd*.so
 	rm -f examples/cgi-demo.cgi
 	rm -rf src/.libs src/.deps doc/*.html doc/*.1 doc/*.txt
diff -u rrdtool-1.4.7/debian/rrdcached.init.d rrdtool-1.4.7/debian/rrdcached.init.d
--- rrdtool-1.4.7/debian/rrdcached.init.d
+++ rrdtool-1.4.7/debian/rrdcached.init.d
@@ -61,6 +61,10 @@
 		return 0
 	fi
 
+	# make sure we have the needed directories
+	mkdir -p /var/lib/rrdcached/journal/
+	mkdir -p /var/lib/rrdcached/db/
+
 	start-stop-daemon --start --quiet --oknodo --pidfile $PIDFILE \
 		--exec $DAEMON -- $OPTS -p $PIDFILE
 }
diff -u rrdtool-1.4.7/debian/changelog rrdtool-1.4.7/debian/changelog
--- rrdtool-1.4.7/debian/changelog
+++ rrdtool-1.4.7/debian/changelog
@@ -1,3 +1,27 @@
+rrdtool (1.4.7-2) unstable; urgency=low
+
+  * Ack NMUs; thanks to Jonathan Wiltshire and gregor herrmann!
+  * Added debian/patches/bts664724-rrdcached-j-segfault:
+Fixed segfault in rrdcached when starting without having the journal
+directory available: canonicalize the journal path after creating the
+directory; else, realpath(3) will return NULL causing strdup() to
+segfault. Also, check the return value of realpath(3) before further using
+it. Thanks to Helmut Grohne for reporting this (Closes: #664724).
+
+ -- Sebastian Harl tok...@debian.org  Wed, 01 Aug 2012 10:23:39 +0200
+
+rrdtool (1.4.7-1.2) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Fix fails to install, postinst, invoke-rc.d rrdcached start, start-
+stop-daemon, segfault:
+(re-)create /var/lib/rrdcached/{journal,db} in init script.
+(Closes: #664724)
+  * debian/rules: remove the generated bindings/perl-shared/MYMETA.yml in the
+clean target.
+
+ -- gregor herrmann gre...@debian.org  Sun, 29 Jul 2012 17:35:13 +0200
+
 rrdtool (1.4.7-1.1) unstable; urgency=low
 
   * Non-maintainer upload.
diff -u rrdtool-1.4.7/debian/patches/series rrdtool-1.4.7/debian/patches/series
--- rrdtool-1.4.7/debian/patches/series
+++ rrdtool-1.4.7/debian/patches/series
@@ -8,0 +9 @@
+bts664724-rrdcached-j-segfault
diff -u rrdtool-1.4.7/debian/patches/ruby_bindings_format_string.patch rrdtool-1.4.7/debian/patches/ruby_bindings_format_string.patch
--- rrdtool-1.4.7/debian/patches/ruby_bindings_format_string.patch
+++ rrdtool-1.4.7/debian/patches/ruby_bindings_format_string.patch
@@ -1,5 +1,5 @@
 Subject: fix format string in Ruby binding
-Author: Johannes Brandstätter jbrandstaet...@gmail.com
+Author: Johannes Brandstätter jbrandstaet...@gmail.com
 Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676081
 Forwarded: no
 Last-Update: 2012-07-01
only in patch2:
unchanged:
--- rrdtool-1.4.7.orig/debian/patches/bts664724-rrdcached-j-segfault
+++ rrdtool-1.4.7/debian/patches/bts664724-rrdcached-j-segfault
@@ -0,0 +1,31 @@
+diff a/src/rrd_daemon.c b/src/rrd_daemon.c
+--- a/src/rrd_daemon.c
 b/src/rrd_daemon.c
+@@ -3090,8 +3090,7 @@ static int read_options (int argc, char **argv) /* {{{ */
+   case 'j':
+   {
+ char journal_dir_actual[PATH_MAX];
+-const char *dir;
+-dir = journal_dir = strdup(realpath((const char *)optarg, journal_dir_actual));
++const char *dir = (const char *)optarg

Bug#683138: [Pkg-nagios-devel] Bug#683138: Bug#683138: pnp4nagios-web: crashes immediately due to debian/patches/adjust-template-path

[Sebastian Harl]

Hi,

On Thu, Aug 02, 2012 at 03:24:23AM +0200, Christoph Anton Mitterer wrote:
 Am 01.08.2012 13:50, schrieb Sebastian Harl:
 I cannot reproduce this behavior.
 Hmm... and you had a clean fresh installation?

No.

 Which version of PHP do you use?
 5.4.4-2

That's the same I used for testing this.

 What
 architecture are you on?
 amd64

 I've tested on amd64 Sid … any other ideas how
 your system might be different from mine?
 Well the base system is stable, but anything pnp4nagios depends on  
 (especially PHP) is from testing.

So, I suppose, you're still using libc from Squeeze, right?

 I run PHP as CGI have some limitations in place, well actually just  
 open_basedir ... as suhosin is non-functiona ATM.
 But the open_basedir includes /etc/pnp4nagios so that shouldn't be  
 aproblem.

Well, I suppose that it would not work either way if that was the
problem ;-)

 So I did some debugging:
 If the dir has no subdirs:
 php -r 'var_dump(glob(/etc/pnp4nagios/templates.d/*, GLOB_ONLYDIR));'
 PHP Warning:  PHP Startup: Unable to load dynamic library  
 '/usr/lib/php5/20100525/suhosin.so' - /usr/lib/php5/20100525/suhosin.so:  
 cannot open shared object file: No such file or directory in Unknown on  
 line 0
 bool(false)


 If it has:
 php -r 'var_dump(glob(/etc/pnp4nagios/templates.d/*, GLOB_ONLYDIR));'
 PHP Warning:  PHP Startup: Unable to load dynamic library  
 '/usr/lib/php5/20100525/suhosin.so' - /usr/lib/php5/20100525/suhosin.so:  
 cannot open shared object file: No such file or directory in Unknown on  
 line 0
 array(3) {
   [0]=
   string(29) /etc/pnp4nagios/templates.d/a
   [1]=
   string(29) /etc/pnp4nagios/templates.d/b
   [2]=
   string(29) /etc/pnp4nagios/templates.d/c
 }


 You can ignore the Suhosin missing warning.

 So I guess the problem is that my PHP doesn't return an empty array but  
 false, which is also documented to be the case on some systems:
 http://php.net/manual/en/function.glob.php

Right. I suppose PHP uses the glob(3) function from libc, so you're
mixed setup might cause that problem. I fully agree that this should
be fixed, but the question is if this bug is to be considered RC.
Anyway, since the patch is fairly trivial, I'll try to get it into
Wheezy -- after all, there might be other architectures / setups that
would cause this problem as well.

Cheers,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#683702: [Pkg-nagios-devel] Bug#683702: pnp4nagios-web: location of the status-header.ssi

[Sebastian Harl]

Hi,

On Fri, Aug 03, 2012 at 01:21:18AM +0200, Christoph Anton Mitterer wrote:
 This is (if at all) just a cosmetic issue:
 Currently status-header.ssi is placed at
 /usr/share/doc/pnp4nagios/examples/ssi/status-header.ssi
 
 Now at one side this is ok,... because it's just an example
 of what can be done with the status-header feature of Nagios/icinga.
 
 On the other side... likely no one will ever modify this and use his
 own version.
 So I guess most people do about the following (using Apache and Icinga as 
 examples)
 to enable it:
 Alias /icinga-cgi-url-path/ssi/status-header.ssi 
 /usr/share/doc/pnp4nagios/examples/ssi/status-header.ssi
 
 
 Well, I can't help but that seems ugly... because status-header.ssi is 
 like executable code... and that should not be in /usr/share/doc/
 
 
 As said I'm not even sure wether this is really better/cleaner... but what do 
 you
 think about moving that into /usr/share/pnp4nagios/ssi ?

Sounds ok for me. I'll look into that after Wheezy ;-)

 Definitely it would be wrong to place them in /usr/share/icinga/htdocs/ssi/
 or it's nagios counterpart!

Ack. I guess, I'll provide a commented out example Alias configuration
in PNP's apache.conf.

 btw: Is it by intention, that you put some of the docs from pnp4nagios-web
 into /usr/share/doc/pnp4nagios/ ?

I'll double-check that. Thanks for the hint.

Cheers,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#664724: rrdtool: diff for NMU version 1.4.7-1.2

[Sebastian Harl]

Hi Gregor,

On Sun, Jul 29, 2012 at 05:45:16PM +0200, gregor herrmann wrote:
 I've prepared an NMU for rrdtool (versioned as 1.4.7-1.2) and
 uploaded it to DELAYED/2. Please feel free to tell me if I
 should delay it longer.

Thanks for taking care of that!

You fix addresses the problem with the default configuration but it will
fail if the user decides to change the data directory for the RRD files.
Ultimately, this needs to be fixed in RRDCacheD. I'll see if I'm able to
find a fix in time for Wheezy.

Cheers,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#683459: [Pkg-nagios-devel] Bug#683459: pnp4nagios-web: include a mod config snippet for icinga

[Sebastian Harl]

Hi,

On Wed, Aug 01, 2012 at 12:18:56AM +0200, Christoph Anton Mitterer wrote:
 This is just a suggestion, but you might wish to include a
 config example snippet for npcdmod for Icinga.
 
 I've already suggested[0] this upstream, but there it was rather
 denied, cause module object definitions are a Icinga-only thingy.
 
 
 Nevertheless, as we have both in Debian, Nagios and Icinga, it may
 be of worth to include such a example config, just as e.g. the
 icinga-idoutils package does it.
 
 Find and exmaple snipped attached.

Thanks for suggesting this and providing a sample. I will include that
in /usr/share/doc, once the outstanding issues for Wheezy have been
fixed.

Cheers,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#683471: [Pkg-nagios-devel] Bug#683471: pnp4nagios: whitespaces in nagios.cfg

[Sebastian Harl]

Hi,

On Wed, Aug 01, 2012 at 03:49:16AM +0200, Christoph Anton Mitterer wrote:
 Attached patch gives all the commands from nagis.cfg the same
 style of whitspace usage.
 
 Yes... I'm a stupid perfectionist ;)

;-)

Thanks!

Cheers,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#683138: [Pkg-nagios-devel] Bug#683138: pnp4nagios-web: crashes immediately due to debian/patches/adjust-template-path

[Sebastian Harl]

tags 683138 + moreinfo
thanks

Hi,

On Sun, Jul 29, 2012 at 04:48:16AM +0200, Christoph Anton Mitterer wrote:
 The support for /etc/pnp4nagios/templates.d seems to be buggy:
 When /etc/pnp4nagios/templates.d is empty (in the sense of no subdirs),
 all I get from pnp4nagios is:
 Please check the documentation for information about the following error.
 
 Invalid argument supplied for foreach()
 file [line]:
 
 /etc/pnp4nagios/config.php [234]:
 
 Guess the reason is that the glob(/etc/pnp4nagios/templates.d/*, 
 GLOB_ONLYDIR)
 returns nothing and then one has a syntax error?!

I cannot reproduce this behavior. Which version of PHP do you use? What
architecture are you on? I've tested on amd64 Sid … any other ideas how
your system might be different from mine?

Cheers,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#682175: [Pkg-nagios-devel] Bug#682175: pnp4nagios: newer upstream version

[Sebastian Harl]

Hi,

On Fri, Jul 20, 2012 at 03:36:07AM +0200, Christoph Anton Mitterer wrote:
 A newer upstream version is available (0.6.18).
 This fixes some things with PHP5.4 which is in wheezy.

These fixes should only be related to Kohana and have already been
applied to 2.3.4-2, which is in Wheezy.

I'll package 0.6.18 soonish but it won't make it into Wheezy (from my
pov, this is not necessary). If you should have any issues remaining in
Wheezy, please open specific bug-reports for those.

TIA,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#681768: gearmand should build-depend on libmemcached-dev = 1.0

[Sebastian Harl]

Package: src:gearmand
Version: 0.33-2
Severity: normal

Hi,

the gearmand configure script checks for libmemcached-dev = 1.0 (rather
than = 0.30 as currently specified in the build-dep). This should be
fixed ;-)

TIA,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#681775: mod-gearman-worker: fails to install if configuration file is missing

[Sebastian Harl]

Package: mod-gearman-worker
Version: 1.3.4-1
Severity: serious
Justification: fails to install

Hi,

when doing a fresh install of mod-gearman-worker that fails with the
following error message:

Configuration file /etc/mod-gearman/worker.conf not present...failed.
invoke-rc.d: initscript mod-gearman-worker, action start failed.
dpkg: error processing mod-gearman-worker (--install):
 subprocess installed post-installation script returned error exit status 1

This is due to the init script (which is called from postinst) aborting
with status 1 if the config is not there. Printing a warning message and
existing with status 0 solves that problem even though I don't exactly
like that either (but it's a problem other packages face as well).

In that particular case, imho two approaches would be (more) sensible:

 - install the sample config by default

 - don't start mod-gearman-worker by default (e.g. thru /etc/default/
   mod-gearman-worker)

Cheers,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#681777: mod-gearman-worker: output of init script broken (missing $DESC)

[Sebastian Harl]

Package: mod-gearman-worker
Version: 1.3.4-1
Severity: minor

Hi,

the mod-gearman-worker init script is missing a declaration for the DESC
variable. Thus, the output of the script looks like this:

Starting : mod_gearman_worker.

Adding something like 'DESC=worker agent for Mod-Gearman' would turn
that into the usual 'Starting worker agent for Mod-Gearman:
mod_gearman_worker'.

Cheers,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#680660: collectd - runs as root without apparent reason

[Sebastian Harl]

Hi,

(Cc'ing the collectd mailing list, hoping for further input and
suggestions. For a full log of this bug report, see
http://bugs.debian.org/680660.)

On Mon, Jul 16, 2012 at 03:19:37PM +0200, Bastian Blank wrote:
 On Sun, Jul 08, 2012 at 02:50:02PM +0200, Sebastian Harl wrote:
  On Sat, Jul 07, 2012 at 10:23:00PM +0200, Bastian Blank wrote:
   All the informations recorded by default are available for normal users
   or at most need CAP_DAC_READSEARCH.
 
 I thought about it and no plugin should need this permission ever. All
 this stuff should be done by group permissions.

There might be plugins requiring some such permission in order to read
information from /proc/ but I haven't double-checked that. I suppose
that would be very few exceptions, though.

  I suggest to do the following: run collectd as nobody (or a newly
  created user 'collectd') by default; make that user configurable through
  /etc/default/collectd
 
 This works with start-stop-daemon. I have one test system run this way.

Yep, that's how I was going to implement that.

make it possible to provide a list of
  capabilities (through /etc/default/collectd) that would be applied to
  the collectd binary in the init script.
 
 This does not work without code modifications. Capabilities in the
 effective and permitted set do not survive execve(2) if not set in the
 filesystem.

Well, I was going to place them in the file-system (if possible). That
would have been a first step in the right direction which would not
require modifications to collectd and would be easy to modify for
testing purposes. Not sure which filesystems support capabilities,
though.

 What collectd should do IMHO:
 - General capability support:
   - Capabilities not known safe are dropped immediately even if run by
 root. It never needs to modify network setup or mount stuff.
 Yes, this may break setups if stuff is not root-owned.
   - Plugins can specify what capabilities they need, they will be
 retained, all others dropped.

Sounds good to me.

This could be implemented by providing a new callback like
'plugin_register_capability'.

 - Support to set user:
   - The process needs to set SECBIT_KEEP_CAPS to retain capabilities
 while changing user from root.

Sounds good to me.

 - Maybe set security bit SECBIT_NOROOT. It removes capabilities from all
   suid-root processes it may try to call.

This would be in the spirit of the exec plugin which refuses to run any
external programs / scripts as root. However, I'm not entirely sure if
that's a good idea, though, as that just limits the possibilities of the
user while I don't see much security benefits.

Cheers,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#680442: tig on a specific file had a better display in squeeze

[Sebastian Harl]

severity 680442 important
thanks

Hi,

On Thu, Jul 05, 2012 at 11:00:19PM +0200, Simon Paillard wrote:
 After upgrading my system from squeeze to wheezy, tig :
 * display nicer graphs when argument is a branch, thanks
 * display weird graph when the argumenet is a file, while 'git log --graph'
   show no branching.
 
 This was ok in squeeze.
 
 Example, using
 http://anonscm.debian.org/gitweb/?p=users/spaillard/pkg-manpages.git;a=summary
 
 tig debian/changelog (which by nature was modified only in a single branch):
 (dropping date and name for better lisibility)
 
 o Fix repeated word in memchr.3 (Closes: #679498)
 │ o 3.41: new manpages
 │ o Prepare 3.41-0.1
 │ │ o [debian/3.40-0.1] Release 3.40-0.1 (final)
 │ │ o debian/changelog: upstream 3.40 closes #156154 #664688
 │ │ │ o Install man1 section in manpages pkg, except time.1 ldd.1
 │ │ │ │ o Release 3.40-0.1
 │ │ │ │ │ o debian/changelog: upstream 3.40 closes #614881 #202022
 [...]
 │ │ │ │ │ │ │ │ │ │ │ │ o Add debian/watch file to track upstream releases
 │ │ │ │ │ │ │ │ │ │ │ │ o Prepare manpages-3.32-1
 │ │ │ │ │ │ │ │ │ │ │ │ │ o [debian/3.27-1] Imported Debian patch 3.27-1

Thanks for reporting this! This regression has already been fixed in
upstream commit 5579a6ff047c0d1b319b5452a8443000921d7da1.

I've raised the severity to important -- imho this should really be
fixed for Wheezy.

 I fear the display for files with many commits..

I've tested that on the README file of git.git … the good news is that
it does work, even though it takes a couple of seconds and the window
really get … well, big ;-)

I'm about to upload a fixed version and ask for a freeze exception.

Cheers,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#681664: unblock: tig/1.0-2

[Sebastian Harl]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package tig (an ncurses-based Git repository browser).

The new upload (version 1.0-2) fixes a regression introduced in 1.0
which more or less renders tig unusable to display the revision history
of a single file. The changes apply an upstream patch available from
upstream's Git repository. See the attached debdiff for details.

I considered switching to 3.0 (quilt) format the smallest change in
order to cleanly apply the new patch. I hope that is fine for you.

unblock tig/1.0-2

TIA,
Sebastian

PS: For the sake of completeness, the upstream Git repo is available at
git://github.com/jonas/tig.git.

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin

debdiff tig_1.0-1_amd64.deb tig_1.0-2_amd64.deb
File lists identical (after any substitutions)

Control files: lines which differ (wdiff format)

Version: [-1.0-1-] {+1.0-2+}


debdiff tig_1.0-1.dsc tig_1.0-2.dsc
diff -Nru tig-1.0/debian/changelog tig-1.0/debian/changelog
--- tig-1.0/debian/changelog2012-07-15 12:40:10.0 +0200
+++ tig-1.0/debian/changelog2012-07-15 11:42:49.0 +0200
@@ -1,4 +1,15 @@
-tig (1.0-1) UNRELEASED; urgency=low
+tig (1.0-2) unstable; urgency=low
+
+  * debian/patches:
+- Added bts680442-broken-graph.patch -- upstream patch fixing a regression
+  breaking the graph when path spec is specified; thanks to Simon Paillard
+  for reporting this (Closes: #680442).
+  * debian/source/format:
+- Change to '3.0 (quilt)' format in order to apply the patch.
+
+ -- Sebastian Harl tok...@debian.org  Sun, 15 Jul 2012 11:42:29 +0200
+
+tig (1.0-1) unstable; urgency=low
 
   * New upstream release; thanks to Salvatore Bonaccorso and Romain Francoise
 for reporting this (Closes: #656810).
diff -Nru tig-1.0/debian/patches/bts680442-broken-graph.patch 
tig-1.0/debian/patches/bts680442-broken-graph.patch
--- tig-1.0/debian/patches/bts680442-broken-graph.patch 1970-01-01 
01:00:00.0 +0100
+++ tig-1.0/debian/patches/bts680442-broken-graph.patch 2012-07-15 
11:36:22.0 +0200
@@ -0,0 +1,67 @@
+Description: Fixed regression breaking the graph when path spec is specified.
+ (cf. upstream commit 5579a6ff047c0d1b319b5452a8443000921d7da1)
+Author: Jonas Fonseca fons...@diku.dk
+
+diff --git a/git.h b/git.h
+index 8179261..e237683 100644
+--- a/git.h
 b/git.h
+@@ -47,9 +47,8 @@
+   GIT_DIFF_INITIAL(, context_arg, space_arg, /dev/null, new_name)
+ 
+ #define GIT_MAIN_LOG(diffargs, revargs, fileargs) \
+-  git, log, ENCODING_ARG, --no-color, --date=raw, \
++  git, log, ENCODING_ARG, --no-color, --pretty=raw, --parents, \
+   opt_commit_order_arg, (diffargs), (revargs), \
+-  --pretty=format:commit %m%H %P%nauthor %an %ae %ad%ntitle 
%s, \
+   --, (fileargs), NULL
+ 
+ #endif
+diff --git a/tig.c b/tig.c
+index 69c3a56..3b26ba1 100644
+--- a/tig.c
 b/tig.c
+@@ -6949,6 +6949,7 @@ main_read(struct view *view, char *line)
+   struct graph *graph = view-private;
+   enum line_type type;
+   struct commit *commit;
++  static bool in_header;
+ 
+   if (!line) {
+   if (!view-lines  !view-prev)
+@@ -6970,6 +6971,7 @@ main_read(struct view *view, char *line)
+   if (type == LINE_COMMIT) {
+   bool is_boundary;
+ 
++  in_header = TRUE;
+   line += STRING_SIZE(commit );
+   is_boundary = *line == '-';
+   if (is_boundary || !isalnum(*line))
+@@ -6985,6 +6987,10 @@ main_read(struct view *view, char *line)
+   return TRUE;
+   commit = view-line[view-lines - 1].data;
+ 
++  /* Empty line separates the commit header from the log itself. */
++  if (*line == '\0')
++  in_header = FALSE;
++
+   switch (type) {
+   case LINE_PARENT:
+   if (!graph-has_parents)
+@@ -7002,7 +7008,15 @@ main_read(struct view *view, char *line)
+   if (commit-title[0])
+   break;
+ 
+-  line += STRING_SIZE(title );
++  /* Skip lines in the commit header. */
++  if (in_header)
++  break;
++
++  /* Require titles to start with a non-space character at the
++   * offset used by git log. */
++  if (strncmp(line, , 4))
++  break;
++  line += 4;
+   /* Well, if the title starts with a whitespace character,
+* try to be forgiving.  Otherwise we end up with no title. */
+   while (isspace(*line))
diff -Nru tig-1.0/debian/patches/series tig-1.0/debian/patches/series
--- tig-1.0/debian/patches/series   1970-01-01 01

Bug#681668: unblock: collectd/5.1.0-3

[Sebastian Harl]

+#   2 if the daemon could not be started
+#   3 if the daemon was not supposed to be started
 d_start() {
if test $DISABLE != 0; then
# we get here during restart
log_progress_msg disabled by /etc/default/$NAME
-   return 2
+   return 3
fi
 
if test ! -e $CONFIGFILE; then
# we get here during restart
log_progress_msg disabled, no configuration ($CONFIGFILE) 
found
-   return 2
+   return 3
fi
 
check_config
rc=$?
-   if test $rc -eq 1; then
+   if test $rc -ne 0; then
log_progress_msg not starting, configuration error
return 2
fi
@@ -105,6 +106,7 @@
--exec $DAEMON -- -C $CONFIGFILE -P $_PIDFILE \
|| return 2
fi
+   return 0
 }
 
 still_running_warning=
@@ -112,6 +114,10 @@
 In large setups it might take some time to write all pending data to
 the disk. You can adjust the waiting time in /etc/default/collectd.
 
+# return:
+#   0 if the daemon has been stopped
+#   1 if the daemon was already stopped
+#   2 if daemon could not be stopped
 d_stop() {
PID=$( cat $_PIDFILE 2 /dev/null ) || true
 
@@ -148,6 +154,8 @@
case $? in
0|1) log_end_msg 0 ;;
2) log_end_msg 1 ;;
+   3) log_end_msg 255; true ;;
+   *) log_end_msg 1 ;;
esac
;;
stop)
@@ -178,7 +186,9 @@
d_start
rc2=$?
case $rc2 in
-   0) log_end_msg 0 ;;
+   0|1) log_end_msg 0 ;;
+   2) log_end_msg 1 ;;
+   3) log_end_msg 255; true ;;
*) log_end_msg 1 ;;
esac
;;
@@ -194,6 +204,4 @@
 esac
 
-exit 0
-
 # vim: syntax=sh noexpandtab sw=4 ts=4 :
 
diff -u collectd-5.1.0/debian/changelog collectd-5.1.0/debian/changelog
--- collectd-5.1.0/debian/changelog
+++ collectd-5.1.0/debian/changelog
@@ -1,3 +1,21 @@
+collectd (5.1.0-3) unstable; urgency=low
+
+  * debian/patches/migrate-4-5-df.dpatch, debian/collectd-core.postinst:
+- Added patch to fix the migration of 'df' values in migrate-4-5.px;
+  thanks to 'markuskaindl' for reporting this on IRC.
+- Pass --rrdfilter and --rrdtool parameters to migrate-4-5.px in order to
+  let the script find those binaries/scripts.
+(Closes: #681363)
+  * debian/collectd-core.collectd.init.d:
+- Catch disabled state in start and restart and don't exit with an error
+  status. Amongst others, this fixes an upgrade of collectd when the
+  daemon is disabled. Thanks to Florian Ernst for reporting this and
+  Evgeni Golov for providing (an early) patch (Closes: #681216).
+- Don't use 'set -e' and 'exit 0' (at the end) in order to let return
+  statuses propagate correctly. (cf. #681216)
+
+ -- Sebastian Harl tok...@debian.org  Sun, 15 Jul 2012 11:17:10 +0200
+
 collectd (5.1.0-2) unstable; urgency=low
 
   * debian/collectd-core.postinst:
diff -u collectd-5.1.0/debian/collectd-core.postinst 
collectd-5.1.0/debian/collectd-core.postinst
--- collectd-5.1.0/debian/collectd-core.postinst
+++ collectd-5.1.0/debian/collectd-core.postinst
@@ -45,7 +45,9 @@
 if [ $RET = true ]; then
 cp -a /var/lib/collectd/ /var/backups/collectd-$2
 /usr/lib/collectd/utils/migrate-4-5.px \
--indir /var/lib/collectd/rrd/ | bash
+--rrdfilter /usr/lib/collectd/utils/rrd_filter.px \
+--rrdtool /usr/bin/rrdtool \
+--indir /var/lib/collectd/rrd/ | bash
 fi
 ;;
 
diff -u collectd-5.1.0/debian/patches/00list 
collectd-5.1.0/debian/patches/00list
--- collectd-5.1.0/debian/patches/00list
+++ collectd-5.1.0/debian/patches/00list
@@ -4,0 +5 @@
+migrate-4-5-df.dpatch
only in patch2:
unchanged:
--- collectd-5.1.0.orig/debian/patches/migrate-4-5-df.dpatch
+++ collectd-5.1.0/debian/patches/migrate-4-5-df.dpatch
@@ -0,0 +1,66 @@
+#! /bin/sh /usr/share/dpatch/dpatch-run
+## migrate-4-5-df.dpatch by Florian Forster o...@collectd.org
+##
+## DP: contrib/migrate-4-5.px: Break up df RRD files into multiple files.
+## DP: cf. upstream commit 605dab534eb2f0ee26446c157c9fdd2ad6e9427a
+
+@DPATCH@
+
+diff --git a/contrib/migrate-4-5.px b/contrib/migrate-4-5.px
+index d3ff796..c39b51b 100755
+--- a/contrib/migrate-4-5.px
 b/contrib/migrate-4-5.px
+@@ -33,6 +33,7 @@ use File::Basename ('dirname');
+ 
+ our $InDir = '/var/lib/collectd';
+ our $RRDtool = 'rrdtool';
++our $RRDFilter = 'rrd_filter.px';
+ 
+ our %TypesCounterToDerive = # {{{
+ (
+@@ -184,7 +185,15 @@ sub handle_file

Bug#681664: unblock: tig/1.0-2

[Sebastian Harl]

Hi KiBi,

On Sun, Jul 15, 2012 at 03:34:03PM +0200, Cyril Brulebois wrote:
 Sebastian Harl tok...@debian.org (15/07/2012):
  The new upload (version 1.0-2) fixes a regression introduced in 1.0
  which more or less renders tig unusable to display the revision
  history of a single file. The changes apply an upstream patch
  available from upstream's Git repository. See the attached debdiff for
  details.
 
 ACK. (Nice UNRELEASED upload. ;p)

Sssh! Nobody has ever seen that so far! ;-P

  I considered switching to 3.0 (quilt) format the smallest change in
  order to cleanly apply the new patch. I hope that is fine for you.
 
 This isn't really appreciated, joy usually doesn't come with source
 format changes, quite the contrary. (Had it been a dh-ified package,
 I would have asked for a --with quilt; but given you would have to
 include quilt.mk and add target dependencies, I guess this is the
 least of the available evils.)

I agree that this was a bit unfortunate, but given that any other
approach would have required a couple of changes as well and since I
didn't come across any problems so far when converting small packages
this sounded like the best solution (least of the available evils is
more to the point ;-)).

  unblock tig/1.0-2
 
 Anyway, unblocked. Thanks for the bug fix.

Thanks for unblocking!

Cheers,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#681668: unblock: collectd/5.1.0-3

[Sebastian Harl]

Hi again,

On Sun, Jul 15, 2012 at 06:16:37PM +0200, Cyril Brulebois wrote:
 Sebastian Harl tok...@debian.org (15/07/2012):
  The upload fixes one important and on RC bug, both fixing upgrade
  issues. Please see the attached debdiff for details.
 
 just to make sure we catch any possible regression while upgrading, I've
 used an “age-days 15” in conjunction with the requested unblock; thanks.

Sounds good to me. Thanks!

Cheers,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#681216: collectd: patch for restart issue

[Sebastian Harl]

Hi,

On Wed, Jul 11, 2012 at 08:01:41PM +0200, Evgeni Golov wrote:
 I have prepared a (trivial) patch, which is attached and solves the 
 issue. No intent to NMU right now.

Thanks for the patch! Please don't NMU since I've got some other stuff
that should be fixed. I'll take care of that shortly.

 --- collectd-5.1.0/debian/collectd-core.collectd.init.d
 +++ collectd-5.1.0/debian/collectd-core.collectd.init.d
 @@ -50,12 +50,12 @@
   . /etc/default/$NAME
  fi
  
 -if test $DISABLE != 0 -a $1 == start; then
 +if test $DISABLE != 0 -a \( $1 == start -o $1 == restart \); then
   log_warning_msg Not starting $DESC, disabled by /etc/default/$NAME.
   exit 0
  fi

Hrm, on restart should the daemon be stopped in that case?
Imho, restart is meant to be something like apply the current
configuration and disabling the daemon is kind of a configuration
setting, so I'd go for stopping collectd.

 -if test ! -e $CONFIGFILE -a $1 == start; then
 +if test ! -e $CONFIGFILE -a \( $1 == start -o $1 == restart \); 
 then
   log_warning_msg Not starting $DESC, no configuration ($CONFIGFILE) 
 found.
   exit 0
  fi

Basically the same applies here as well.

Cheers,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#681363: collectd: fails to migrate 'df' values on upgrade to 5.x

[Sebastian Harl]

Package: collectd
Version: 5.1.0-1
Severity: important
Tags: patch

Hi,

when upgrading from 4.x to 5.x, the migrate-4-5 script fails to
correctly migrate values collected by the 'df' plugin, leaving behind
unusable 'df' RRD files.

This has been fixed upstream in commit
http://git.verplant.org/?p=collectd.git;a=commitdiff;h=605dab534eb2f0ee26446c157c9fdd2ad6e9427a

Cheers,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#680658: collectd - rrd module takes umask a bit too serious

[Sebastian Harl]

Hi,

On Sat, Jul 07, 2012 at 10:09:40PM +0200, Bastian Blank wrote:
 The rrdtool module creates all stuff using the umask of the process. So
 depending on the environment, directories are readable, writable or
 nothing:
 
 | drwxr-x---  2 root root 4096 Jun 28 18:43 uptime/
 | drwxr-xr-x  2 root root 4096 Jun 28 16:12 users/

Hrm, I fail to see why this is a bug in collectd. Imho, this is the
expected behavior and I suppose most software behaves like that. It
might make sense to explicitly set the umask in the init script, though.

Cheers,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#680660: collectd - runs as root without apparent reason

[Sebastian Harl]

Hi,

On Sat, Jul 07, 2012 at 10:23:00PM +0200, Bastian Blank wrote:
 All the informations recorded by default are available for normal users
 or at most need CAP_DAC_READSEARCH. There is no reason to run collectd
 with the highest permissions on the system.

Agreed. Another (I suppose) commonly required capability is CAP_NET_RAW
(required by the ping plugin.

I suggest to do the following: run collectd as nobody (or a newly
created user 'collectd') by default; make that user configurable through
/etc/default/collectd and make it possible to provide a list of
capabilities (through /etc/default/collectd) that would be applied to
the collectd binary in the init script.

Does that sound sane to you?

Cheers,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature