Bug#964586: O: powerman -- Centralized Power Distribution Unit (PDU) management

[Arnaud Quette]

Package: wnpp
Severity: normal

I intend to orphan the powerman package, since I'm retiring from Debian.

I'm unsure if this software is still useful, considering the
popcorn figures.
So it may be considered for a removal from the archives.

cheers,
Arno

Bug#964585: O: pwrkap -- Energy use monitor and Power Cap enforcement tools - Core

[Arnaud Quette]

Package: wnpp
Severity: normal

I intend to orphan the wmnut package, since I'm retiring from Debian.

I no longer have time to maintain this package.
I'm unsure if this software is still useful, considering the
popcorn figures.
So it may be considered for a removal from the archives.

cheers,
Arno

Bug#964584: Please remove me from the Uploaders

[Arnaud Quette]

Package: pylirc
Severity: normal

I'm in the process of retiring from Debian.
So please remove myself from the Uploaders list.

Thanks and cheers,
Arno

Bug#964583: O: wmnut -- WindowMaker dock app that displays UPS statistics from NUT upsd

[Arnaud Quette]

Package: wnpp
Severity: normal

I intend to orphan the wmnut package, since I'm retiring from Debian.

I no longer have time to maintain this package. This software seems still
useful, though (as the upstream author) I don't intend to update it anymore.

I've uploaded the code to Salsa, and update the control file:

https://salsa.debian.org/debian/wmnut

cheers,
Arno

Bug#812604: nut-server: usbhid-ups segfaults due to missing USB strings

[Arnaud Quette]

FYI
I've also made a somewhat complementary patch that tries 3 times to get
these string (only once currently elsewhere).
Iirc it's still sitting in the libusb1 branch on github, and it's not yet
merged in the mainline. Would be cool if you could test...

Cheers,
Arno

Bug#861745: [Pkg-utopia-maintainers] Bug#861745: dbus: Make adduser / perl Depends optional

[Arnaud Quette]

2017-05-03 15:23 GMT+02:00 Michael Biebl <bi...@debian.org>:

> Hi Arno
>

Hi Michael

Long time no see, I hope you're doing fine


>
> Am 03.05.2017 um 14:47 schrieb Arnaud Quette:
>
> > we have a project at Eaton related to 42ITy <http://42ity.org>, which
> > produce a Debian derivative for a HW appliance. For storage footprint
> > reason, we've gotten rid of perl. Now, we're adding avahi, which pulls
> > dbus, which pulls perl through the adduser command and Depends.
> >
> > The attached patch moves adduser to Suggests, and use adduser only if
> > available. It otherwise fallback to useradd.
> >
> > Note: there is a small nuance between useradd and adduser: the latter
> tries
> > to use the smallest UID/GID for system users, while the former goes top
> > down from SYS_UID_MAX.
> > As an example, the original dbus postinst ended up with UID/GID 146 on my
> > system, while the modified has 999…
>
> While I understand your incentive, I'm not sure this is the right
> approach. There are a lot of packages requiring adduser. Adding a
> fallback to every one of them doesn't seem right.
>

indeed! I only intended to do a local fix for the specific dbus issue we
have.

Why don't you provide a adduser package in your derivative, which does
> not require perl? It could even be a small shell wrapper around useradd.
>

I was thinking about this, but prefered the more straightforward / less
time consuming focused fix.
I still keep this in mind however, since we (Eaton / 42ITy) intend to
release all our changes / mods / improvements to Debian.
In the long run, we intend to have no diff with Debian, but that can take
some time ;)


> So, from my POV this bug report is a wontfix as I think it's the wrong
> approach. But let's see what Simon, the main dbus maintainer, thinks.
>

makes sense. again, this is more a hotfix for a specific issue / need on
our side.
but it's interesting to get feedback and see if other peoples are facing
the same kind of things...
looking forward Simon's answer

2017-05-03 15:32 GMT+02:00 Michael Biebl <bi...@debian.org>:

>
> Looking again, it seems adduser itself does not actually depend on perl,
> I suppose it only requires perl-base, which is essential.
> Getting rid of perl-base sounds like a lot of work, as packages are free
> to rely on its functionality without having to depend on it. So you'd
> have to check a lot of packages.
>

indeed, adduser depends on perl-base not perl.
Reverse deps on adduser announces 799 packages
that's a lot more than I can handle on the little time I have currently ;)
I'll try to dig the 'adduser-noperl' approach to see if I can get something
out of this.

thanks and cheers,
Arno
-- 
Eaton Data Center Automation Solutions - Opensource Leader -
http://42ity.org
NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.fr

Bug#861745: dbus: Make adduser / perl Depends optional

[Arnaud Quette]

Package: dbus
Severity: wishlist
Tags: patch

Hi,

we have a project at Eaton related to 42ITy , which
produce a Debian derivative for a HW appliance. For storage footprint
reason, we've gotten rid of perl. Now, we're adding avahi, which pulls
dbus, which pulls perl through the adduser command and Depends.

The attached patch moves adduser to Suggests, and use adduser only if
available. It otherwise fallback to useradd.

Note: there is a small nuance between useradd and adduser: the latter tries
to use the smallest UID/GID for system users, while the former goes top
down from SYS_UID_MAX.
As an example, the original dbus postinst ended up with UID/GID 146 on my
system, while the modified has 999…

Thanks for considering its integration,
Cheers,
Arno
-- 
Eaton Data Center Automation Solutions - Opensource Leader -
http://42ity.org
NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.fr


dbus-noperl-adduser.patch
Description: application/mbox

Bug#851015: nut: FTBFS: a2x: ERROR: missing configuration file: /etc/asciidoc/dblatex/asciidoc-dblatex.xsl

[Arnaud Quette]

Hi Michael,

No idea on the why and not much time to look at it before the week end.
Iirc, dblatex is listed for the manpages generation.

Feel free to upload a fix if you find one.

Thanks and cheers.
Arno

Le 19 janv. 2017 19:57, "Michael Stapelberg"  a
écrit :

> [+aquette, bigon directly]
>
> Are you aware of this issue? This RC bug transitively marked freeradius
> for removal from testing. If you need help, please let me know — I have
> some incentive to look into it in order to keep freeradius in stretch.
>
> Lucas Nussbaum  writes:
>
> > Source: nut
> > Version: 2.7.4-4
> > Severity: serious
> > Tags: stretch sid
> > User: debian...@lists.debian.org
> > Usertags: qa-ftbfs-20170111 qa-ftbfs
> > Justification: FTBFS on amd64
> >
> > Hi,
> >
> > During a rebuild of all packages in sid, your package failed to build on
> > amd64.
> >
> > Relevant part (hopefully):
> >> make[3]: Entering directory '/<>/docs'
> >> make[3]: Nothing to be done for 'all-am'.
> >> make[3]: Leaving directory '/<>/docs'
> >> /usr/bin/a2x  --attribute icons --xsltproc-opts "--nonet"
> --xsltproc-opts "--stringparam nut.localdate \"`TZ=UTC date +%Y-%m-%d`\""
> --xsltproc-opts "--stringparam nut.localtime \"`TZ=UTC date +%H:%M:%S`\""
> --xsltproc-opts "--stringparam nut.nutversion \"2.7.4\"" --attribute
> iconsdir=./images --attribute=badges --attribute=external_title --attribute
> tree_version=2.7 -a toc -a numbered --destination-dir=.
> --attribute=chunked_format --format=chunked --xsl-file=./chunked.xsl
> user-manual.txt
> >> /usr/bin/a2x  --attribute icons --xsltproc-opts "--nonet"
> --xsltproc-opts "--stringparam nut.localdate \"`TZ=UTC date +%Y-%m-%d`\""
> --xsltproc-opts "--stringparam nut.localtime \"`TZ=UTC date +%H:%M:%S`\""
> --xsltproc-opts "--stringparam nut.nutversion \"2.7.4\"" --attribute
> iconsdir=./images --attribute=badges --attribute=external_title --attribute
> tree_version=2.7 -a toc -a numbered --destination-dir=.
> --attribute=chunked_format --format=chunked --xsl-file=./chunked.xsl
> developer-guide.txt
> >> /usr/bin/a2x  --attribute icons --xsltproc-opts "--nonet"
> --xsltproc-opts "--stringparam nut.localdate \"`TZ=UTC date +%Y-%m-%d`\""
> --xsltproc-opts "--stringparam nut.localtime \"`TZ=UTC date +%H:%M:%S`\""
> --xsltproc-opts "--stringparam nut.nutversion \"2.7.4\"" --attribute
> iconsdir=./images --attribute=badges --attribute=external_title --attribute
> tree_version=2.7 -a toc -a numbered --destination-dir=.
> --attribute=chunked_format --format=chunked --xsl-file=./chunked.xsl
> packager-guide.txt
> >> /usr/bin/a2x  --attribute icons --xsltproc-opts "--nonet"
> --xsltproc-opts "--stringparam nut.localdate \"`TZ=UTC date +%Y-%m-%d`\""
> --xsltproc-opts "--stringparam nut.localtime \"`TZ=UTC date +%H:%M:%S`\""
> --xsltproc-opts "--stringparam nut.nutversion \"2.7.4\"" --attribute
> iconsdir=./images --attribute=badges --attribute=external_title --attribute
> tree_version=2.7 -a toc -a numbered --destination-dir=.
> --attribute=xhtml11_format --format=xhtml --xsl-file=./xhtml.xsl FAQ.txt
> >> /usr/bin/a2x  --attribute icons --xsltproc-opts "--nonet"
> --xsltproc-opts "--stringparam nut.localdate \"`TZ=UTC date +%Y-%m-%d`\""
> --xsltproc-opts "--stringparam nut.localtime \"`TZ=UTC date +%H:%M:%S`\""
> --xsltproc-opts "--stringparam nut.nutversion \"2.7.4\"" --attribute
> iconsdir=./images --attribute=badges --attribute=external_title --attribute
> tree_version=2.7 -a toc -a numbered --destination-dir=.
> --attribute=pdf_format --format=pdf -a docinfo1 user-manual.txt
> >> a2x: WARNING: --destination-dir option is only applicable to HTML based
> outputs
> >> a2x: ERROR: missing configuration file: /etc/asciidoc/dblatex/
> asciidoc-dblatex.xsl
> >> Makefile:825: recipe for target 'user-manual.pdf' failed
> >> make[2]: *** [user-manual.pdf] Error 1
> >
> > The full build log is available from:
> >http://aws-logs.debian.net/2017/01/11/nut_2.7.4-4_unstable.log
> >
> > A list of current common problems and possible solutions is available at
> > http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to
> contribute!
> >
> > About the archive rebuild: The rebuild was done on EC2 VM instances from
> > Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
> > failed build was retried once to eliminate random failures.
> >
> >
>
> --
> Best regards,
> Michael
>

Bug#791625: nut: Can't talk to Eaton 5S

[Arnaud Quette]

2016-12-24 15:23 GMT+01:00 Kurt Roeckx <k...@roeckx.be>:

> On Sat, Dec 24, 2016 at 02:56:53PM +0100, Arnaud Quette wrote:
> > Hi Kurt,
> >
> > are you still facing this issue?
> > As far as I recall, I've tested 5S not long ago (Jessie + NUT 2.7.4), and
> > everything was fine...
>
> As far as I know, it works sometimes. It ussually works when
> they're both just up. But I think the 5S gets confused if you ever
> stop nut.
>
> We also just stopped using the 5S. We've already had 2 of them
> just shut down the power to the server while there was nothing
> wrong with the power and it had power itself. It then indicates
> some internal error. We've replaced them by APCs.
>
> I have no idea if the above 2 issues are related or not.
>
>
Hi Kurt,

thanks for your fast answer.
I've cc'ed myself @work, to push that to the support and validation team,
and check the exact situation.
Sorry for the issues you've encountered, I hope that Eaton will recover
your trust in a soon future.

In the meantime, I wish you a merry Christmas.

Cheers,
Arno
-- 
Eaton Data Center Automation Solutions - Opensource Leader -
http://42ity.org
NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.fr

Bug#791625: nut: Can't talk to Eaton 5S

[Arnaud Quette]

Hi Kurt,

are you still facing this issue?
As far as I recall, I've tested 5S not long ago (Jessie + NUT 2.7.4), and
everything was fine...

thanks and cheers,
Arno
-- 
Eaton Data Center Automation Solutions - Opensource Leader -
http://42ity.org
NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.fr

Bug#840754: Memory leak in libmagic and failure in magic_load

[Arnaud Quette]

2016-12-02 0:04 GMT+01:00 Christoph Biedl <debian.a...@manchmal.in-ulm.de>:
> Arnaud Quette wrote...
>
>> $ gcc test.c -lmagic
>> valgrind ./a.out
> (...)
>> ==30967== HEAP SUMMARY:
>> ==30967== in use at exit: 48 bytes in 3 blocks
>> ==30967== total heap usage: 28 allocs, 25 frees, 2,179 bytes allocated
> (...)
>
> Hello,
>
> according to my tests this was fixed in file/libmagic 5.29-1 (as in
> sid and stretch):
>
> ==416629== Memcheck, a memory error detector
> ==416629== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
> ==416629== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright 
> info
> ==416629== Command: ./a.out
> ==416629==
> ==416629==
> ==416629== HEAP SUMMARY:
> ==416629== in use at exit: 0 bytes in 0 blocks
> ==416629==   total heap usage: 16 allocs, 16 frees, 1,123 bytes allocated
> ==416629==
> ==416629== All heap blocks were freed -- no leaks are possible
> ==416629==
> ==416629== For counts of detected and suppressed errors, rerun with: -v
> ==416629== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
>
> Please confirm, I'll prepare a fix for jessie then (wheezy is
> appearently not affected).

Hi Christoph,

I confirm that libmagic 5.29-1 (tested on stretch) fixes the issue.

thanks and cheers,
Arno
-- 
Eaton Data Center Automation Solutions - Opensource Leader - http://42ity.org
NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.fr

Bug#840754: Memory leak in libmagic and failure in magic_load

[Arnaud Quette]

Hi Christoph,

2016-10-17 20:21 GMT+02:00 Christoph Biedl <debian.a...@manchmal.in-ulm.de>:
> tags 840754 confirmed moreinfo
> thanks
>
> Arnaud Quette wrote...
>
>> ==30967== definitely lost: 48 bytes in 1 blocks
>
> Confirmed, can reproduce this from jessie on, not in wheezy though.
>
>> - Redhat has a similar ticket which they solved:
>> https://bugzilla.redhat.com/show_bug.cgi?id=919466
>
> Unfortunately I fail to see the actual fix for this (and I'm also
> somewhat surprised why it never made upstream, but that's a different
> story).
>
> Since you added the patch tag, do you have some details available?

looking closer at the patch I pointed, it's very probably not suitable.
IMHO, it's Debian related, though I've not tested on Redhat nor others.
As per my original report, the issue is with the return value of
get_default_magic(), which is "/etc/magic" instead of the documented
default "/usr/share/misc/magic" (using "MAGIC=/usr/share/misc/magic
valgrind ./a.out" shows no leak).
Not sure how other distros ships the magic.mgc
Another point is that removing (or renaming) /etc/magic also fixes the issue.

I was not able to hunt the bug yet, but here is some details.
- magic.c->magic_getpath return "/etc/magic:/usr/share/misc/magic"
- the processing of /etc/magic goes fine, but the loops then leak when
processing /usr/share/misc/magic
- the leak happen in apprentice.c->apprentice_1() when calling
add_mlist(). Still not sure why, I don't quite get the deeper logic of
this code.

I'll try to dig more and find a suitable patch, but kids vacations are
on the way in the short run...

again, the simple solution, while waiting for fixing the code, may be
to export MAGIC=/usr/share/misc/magic

Do you want me to remove the patch tag, or do you consider the
"export" solution as being a patch?

cheers,
Arno
-- 
Eaton Data Center Automation Solutions - Opensource Leader
NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.fr

Bug#840754: Memory leak in libmagic and failure in magic_load

[Arnaud Quette]

Package: libmagic1
Version: 1:5.22+15-2+deb8u2
Severity: normal

libmagic suffers from a memory leak, apparently due to magic_load()
not satisfying its contract:0

As per man magic_load:
--
The magic_load() function must be used to load the the colon separated
list of database files passed in as filename, or NULL for the default
database file before any magic queries can performed.

The default database file is named by the MAGIC environment variable.
If that variable is not set, the default database file name is
/usr/share/misc/magic.  magic_load() adds “.mgc” to the database
filename as appropriate.
--

Steps to reproduce:

$ cat test.c
#include 
#include 

int main ()
{ magic_t _magic = magic_open (MAGIC_MIME); int r = magic_load
(_magic, NULL); magic_close (_magic); }

$ gcc test.c -lmagic
valgrind ./a.out
==30967== Memcheck, a memory error detector
==30967== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==30967== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==30967== Command: ./a.out
==30967==
==30967==
==30967== HEAP SUMMARY:
==30967== in use at exit: 48 bytes in 3 blocks
==30967== total heap usage: 28 allocs, 25 frees, 2,179 bytes allocated
==30967==
==30967== LEAK SUMMARY:
==30967== definitely lost: 48 bytes in 1 blocks
==30967== indirectly lost: 0 bytes in 2 blocks
==30967== possibly lost: 0 bytes in 0 blocks
==30967== still reachable: 0 bytes in 0 blocks
==30967== suppressed: 0 bytes in 0 blocks
==30967== Rerun with --leak-check=full to see details of leaked memory
==30967==
==30967== For counts of detected and suppressed errors, rerun with: -v
==30967== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

To fix the above, either:
- use "MAGIC=/usr/share/misc/magic valgrind ./a.out"
- or modify the above test code "magic_load (_magic, "/usr/share/misc/magic")

It turns out the private function get_default_magic() returns
"/etc/magic" instead of the document default "/usr/share/misc/magic",
which in turns generates some lost blocks.

Solution:

Either fix upstream or export the MAGIC environment variable (probably
better / easier considering the code!).

Side notes:
- Reported with details by Michal Vyskocil from the Eaton Opensource Team
- Redhat has a similar ticket which they solved:
https://bugzilla.redhat.com/show_bug.cgi?id=919466

cheers,
Arno
-- 
Eaton Data Center Automation Solutions - Opensource Leader
NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.fr

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

[Arnaud Quette]

2016-09-25 12:09 GMT+02:00 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



Hi Sebastian,

please go ahead and NMU if Laurent is also busy.

Thanks for the help,
Arno

Bug#780763: (nut install won't complete because of service start check)

[Arnaud Quette]

Le 19 mars 2015 14:21, Stomptemp a écrit :


 Hello, I just saw bug#747863 which looks like it is the same thing, but
for the nut-client package.  Maybe the same issue exists in the nut-server
package?
 Josh

Exactly Josh.
Arno

Bug#630761: RFP: libczmq -- High-level C binding for ZeroMQ

[Arnaud Quette]

retitle 630761 ITP: libczmq -- High-level C binding for ZeroMQ
owner 630761 aque...@debian.org
thanks

Hi,

I'm intending to take over the packaging of libczmq.

I'll start by pushing the last stable (2.2.0) to collab-maint [0] (ready to
push). Packages are ready for upload too.
But please note that since I'm not (yet) a user of czmq, I may be missing
something.
So, any help, info, hint, test, ... will be welcome.

For further steps, I'll need to talk with the upstream (Pieter Hintjens,
cc'ed, is the upstream leader), to get visibility on the 3.0.0 timelines
and general roadmap.

Thanks to those of you cc'ed, for having paved the road!

cheers,
Arno
--
[0] http://git.debian.org/?p=collab-maint/czmq.git
-- 
Eaton Data Center Automation - Opensource Leader
NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.fr

Bug#755913: Provide an iproute2-dev package

[Arnaud Quette]

package:iproute2
version: 3.15.0-2

Over the transition from iproute to iproute2 [1], the iproute2-dev package
was lost [2].

Could you please provide it, along with a transition iproute-dev package to
iproute2-dev?
Or otherwise, is there any reason to have removed it?
I know there is libnl and libmnl, but would rather first consider keeping
the current iproute-based code as is...

thanks and cheers,
Arno
--
[1] https://wiki.debian.org/Teams/pkg-iproute
[2]
http://anonscm.debian.org/cgit/collab-maint/pkg-iproute.git/commit/debian/control?id=088816b167ff7ad531f01e13aeda65f210b7545d
-- 
Eaton Data Center Automation - Opensource Leader
NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.fr

Bug#710238: nut-snmp: continously logging dstate_setflags: base variable (xxxx...) is immutable

[Arnaud Quette]

2013-04-04 12:01 GMT+02:00 Zdenek Herman zde...@ille.cz:

 Package: nut-snmp
 Version: 2.6.4-2.3
 Severity: minor

 Hello
 I have installed nut with snmp driver.
 After setting ignorelb and override.battery.runtime.low = 600 in
 ups.conf
 my logs are filled:

 May 29 11:11:34 host snmp-ups[35762]: dstate_setflags: base variable (
 battery.ru
 ntime.low) is immutable
 May 29 11:11:50 host snmp-ups[35762]: dstate_setflags: base variable (
 battery.ru
 ntime.low) is immutable
 May 29 11:12:06 host snmp-ups[35762]: dstate_setflags: base variable (
 battery.ru
 ntime.low) is immutable
 May 29 11:12:22 host snmp-ups[35762]: dstate_setflags: base variable (
 battery.ru
 ntime.low) is immutable
 May 29 11:12:38 host snmp-ups[35762]: dstate_setflags: base variable (
 battery.ru
 ntime.low) is immutable


 I think that is sufficient once after start daemon.


have you provided a community (or v3 credentials) that allows to write in
your MIB?

Arno

Bug#710238: nut-snmp: continously logging dstate_setflags: base variable (xxxx...) is immutable

[Arnaud Quette]

2014-05-19 23:07 GMT+02:00 Arnaud Quette aquette@gmail.com:



 2013-04-04 12:01 GMT+02:00 Zdenek Herman zde...@ille.cz:

 Package: nut-snmp
 Version: 2.6.4-2.3
 Severity: minor

 Hello
 I have installed nut with snmp driver.
 After setting ignorelb and override.battery.runtime.low = 600 in
 ups.conf
 my logs are filled:

 May 29 11:11:34 host snmp-ups[35762]: dstate_setflags: base variable (
 battery.ru
 ntime.low) is immutable
 May 29 11:11:50 host snmp-ups[35762]: dstate_setflags: base variable (
 battery.ru
 ntime.low) is immutable
 May 29 11:12:06 host snmp-ups[35762]: dstate_setflags: base variable (
 battery.ru
 ntime.low) is immutable
 May 29 11:12:22 host snmp-ups[35762]: dstate_setflags: base variable (
 battery.ru
 ntime.low) is immutable
 May 29 11:12:38 host snmp-ups[35762]: dstate_setflags: base variable (
 battery.ru
 ntime.low) is immutable


 I think that is sufficient once after start daemon.


 have you provided a community (or v3 credentials) that allows to write in
 your MIB?


I forgot to add that, after check, only the APC MIB can export this setting.
Others simply report it, but don't allow changes (this may be mixed, if
possible, and with some users help!).
do you know which MIB you're using?

Arno

Bug#694622: nut-snmp

[Arnaud Quette]

I can confirm that it works elsewhere.
Note that the value 'apc' in port must be resolved as an IP address...

Arno
(sent from my S3... please excuse my brevity)
Le 9 févr. 2013 12:45, Ivo De Decker ivo.dedec...@ugent.be a écrit :

 Control: severity -1 normal

 Hi,

 On Wed, Feb 06, 2013 at 08:28:53PM +0100, Michael Stapelberg wrote:
   ups.conf
   [apcpdu]
   driver = snmp-ups
   port = apc
   mibs = apcc
   community = public
  Try removing the “mibs = apcc” line.
  Also, maybe specify “snmp_version = v1”.

 A simple test show that the line 'mibs = apcc' is not accepted by nut, so
 this
 is a configuration problem. This means the bug is certainly not 'grave', so
 I'm downgrading it. If someone can confirm that it works with a different
 config, this bug can probably be closed.

 Cheers,

 Ivo

Bug#684732: unblock: nut/2.6.4-2

[Arnaud Quette]

All

Thanks a lot for your work! I've quickly checked (with a limited mobile
terminal) and everything seems fine.
Sorry for being MIA here,  but it will probably be for some more time...

All the best for end of the year celebrations.
Cheers,
Arnaud
(sent from my S3... please excuse my brevity)
Le 20 déc. 2012 20:47, Ivo De Decker ivo.dedec...@ugent.be a écrit :

 Hi Laurent,

 On Thu, Dec 20, 2012 at 08:19:21PM +0100, Laurent Bigonville wrote:
   I prepared an NMU that should fix both issues. The debdiff against
   wheezy and the debdiff -w against sid are attached. I will try to get
   this NMU uploaded soon.
 
  Looks good but (there is always a but :), /etc/init.d/nut is shipped in
  the nut package in squeeze, so I guess it should also be removed when
  upgrading that package. And in case of partial upgrade, I guess you also
  want to remove it when the nut-client package is installed as it will
  cause issue if both /etc/init.d/nut and /etc/init.d/nut-client are
  trying to start the same components.
 
  So I would say, remove it when upgrading nut, nut-client and nut-server
  (which is already the case). Am I correct here?

 Thanks for the review.

 I added it to nut-client as well (new debdiffs attached). Adding it to nut
 is
 not necessary, because nut depends on nut-client and nut-server, so if nut
 is
 installed, the old init script will be removed anyway by nut-client or
 nut-server.

 Cheers,

 Ivo

Bug#684732: unblock: nut/2.6.4-2

[Arnaud Quette]

Hi everybody,

sorry for the lag in answering... too many real life issues to deal with.

2012/11/26 Julien Cristau jcris...@debian.org

 On Sun, Nov 11, 2012 at 22:42:09 +0100, Laurent Bigonville wrote:

  Le Sun, 11 Nov 2012 19:06:52 +0100,
  Julien Cristau jcris...@debian.org a écrit :
 
   One more question...
  
   On Mon, Aug 13, 2012 at 15:36:14 +0200, Laurent Bigonville wrote:
  
+for file in nut.conf upsmon.conf upssched.conf ; do
+if [ -f /etc/nut/$file ] ; then
+chown root:nut /etc/nut/$file
+chmod 640 /etc/nut/$file
+fi
+done
  
   why is this is done unconditionally on postinst configure, instead of
   just on first install?
 
  These files could contains passwords, I guess that this is done to be
  really sure the files are not world readable? Arnaud?
 
 Doing that when the file is created is fine.  But not every time
 postinst runs, IMO.


this is indeed to enforce that files have still the proper permissions for
the nut user, as mentioned by Laurent, since we still lack a configuration
tool to assist this.  Having anything else than the above may results in
NUT not being able to start or some security hole.

I don't see any specific issue with this one.

cheers,
Arnaud
-- 
NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.fr

Bug#684732: unblock: nut/2.6.4-2

[Arnaud Quette]

Hi Michael,

2012/11/26 Michael Biebl bi...@debian.org

 On 26.11.2012 01:58, Michael Biebl wrote:
  +if [ -d /var/run/nut ] ; then
  +chown root:nut /var/run/nut
  +chmod 770 /var/run/nut
  +fi

  d /var/run/nut 0770 nut nut - -

 A small bug slipped through, the correct config would be

 d /var/run/nut 0770 root nut - -


thanks for pointing this. this will complete nut systemd support.
I'll also be looking at it.

cheers,
Arnaud
-- 
Engineering Linux/Unix Expert - Opensource Solutions Lead - Eaton -
http://opensource.eaton.com
NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.fr

Bug#684732: unblock: nut/2.6.4-2

[Arnaud Quette]

I missed to add...

2012/11/26 Arnaud Quette aquette@gmail.com

 Hi Michael,


 2012/11/26 Michael Biebl bi...@debian.org

 On 26.11.2012 01:58, Michael Biebl wrote:
  +if [ -d /var/run/nut ] ; then
  +chown root:nut /var/run/nut
  +chmod 770 /var/run/nut
  +fi


this specific snippet is indeed redundant with init scripts, and so not
useful anymore since the creation at startup time will take care of both
the directory creation and permissions settings.

It may be removed, though it doesn't harm.


  d /var/run/nut 0770 nut nut - -

 A small bug slipped through, the correct config would be

 d /var/run/nut 0770 root nut - -


 thanks for pointing this. this will complete nut systemd support.
 I'll also be looking at it.



cheers,
Arnaud
-- 
Engineering Linux/Unix Expert - Opensource Solutions Lead - Eaton -
http://opensource.eaton.com
NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.fr

Bug#677054: nut-client: prompting due to modified conffiles which were not modified by the user

[Arnaud Quette]

Hi Sebastien

2012/11/23 Sébastien Villemot sebast...@debian.org

 Control: tags -1 + patch

 Laurent Bigonville bi...@debian.org writes:

  The bug (maintainer script modifying conffile) that bring us to this
  situation (prompting the user for a file he has not modified himself)
  is not happening in the version in wheezy and the root cause is fixed
  (bug #684392) in sid.
 
  The user will still be prompted when upgrading from squeeze (that's
  why I didn't close that bug) BUT chances, in a normal situation, that
  the user didn't changed that file by himself is close to zero, as that
  file is controlling which part of the NUT software
  (client/server/standalone) is running.
 
  If somebody want to provide a patch, I would apply it with joy but I'm
  quite busy now and I'm not sure how to do that properly (handling
  upgrade being aborted,...).

 Please find attached a patch that should fix this bug. It implements the
 dirty hack in nut-client.preinst. With this patch applied, upgrades from
 squeeze go without smoothly without prompting.


this should indeed fix the issue, as best as it can, considering the big
mess of this situation.

Could you please also handle the NMU?
Thanks a lot for your patch.

cheers,
Arnaud
-- 
Engineering Linux/Unix Expert - Opensource Solutions Lead - Eaton -
http://opensource.eaton.com
NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.fr

Bug#684732: unblock: nut/2.6.4-2

[Arnaud Quette]

Hi Laurent and Julien,

2012/11/11 Laurent Bigonville bi...@debian.org

 Le Sun, 11 Nov 2012 19:06:52 +0100,
 Julien Cristau jcris...@debian.org a écrit :

  One more question...
 
  On Mon, Aug 13, 2012 at 15:36:14 +0200, Laurent Bigonville wrote:
 
   +for file in nut.conf upsmon.conf upssched.conf ; do
   +if [ -f /etc/nut/$file ] ; then
   +chown root:nut /etc/nut/$file
   +chmod 640 /etc/nut/$file
   +fi
   +done
 
  why is this is done unconditionally on postinst configure, instead of
  just on first install?

 These files could contains passwords, I guess that this is done to be
 really sure the files are not world readable? Arnaud?


this is indeed to enforce security on these files, as Laurent said:
ups.conf may contains SNMP credentials, upsd.users and upsmon.conf contain
NUT internal users password.

Thus, it's *mandatory* to ensure protection. The above is just a test upon
install / update, but the same is planned for the configuration editing
library and tools (work underway).

cheers,
Arnaud
-- 
Linux / Unix / Opensource Engineering Expert - Eaton -
http://opensource.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.fr

Bug#684732: unblock: nut/2.6.4-2

[Arnaud Quette]

Hi again guys,

2012/11/11 Laurent Bigonville bi...@debian.org

 Le Sun, 11 Nov 2012 19:07:46 +0100,
 Julien Cristau jcris...@debian.org a écrit :

  On Sat, Sep 29, 2012 at 21:12:09 +0200, Laurent Bigonville wrote:
 
   Le Sat, 29 Sep 2012 20:56:11 +0200,
   Julien Cristau jcris...@debian.org a écrit :
  
   
why is the last bit needed?
   
 
  I didn't get a reply to the above (why you need adduser nut nut).

 See #493159

 This is to fix a situation were the user nut was not created without
 being added to the group. Is that correct Arnaud?


indeed, we have some corner cases due to the modular and distributed nature
of NUT:
you may install the CGI alone, to monitor remote installation, then install
nut (server | client ...) in the meantime, uninstall either ones, and still
requires the user and group to be there.


 
+if [ -d /var/run/nut ] ; then
+chown root:nut /var/run/nut
+chmod 770 /var/run/nut
+fi
   
why does the nut user need write access there?  And why is this
created in postinst instead of an init script?
  
   nut should be able to create sockets in that directory.
  
   This is probably a bit redundant as this is also done in the
   initscript.
  
  Then I'd prefer to not have it in postinst.

 Well this was a copy/paste of the nut-server postinstall script, so
 this should also be removed from that file too. Do you want me to do
 that for wheezy?


right, that's part of the legacy (dead) code, prior to the volatile /var
move.
good to remove, since it's addressed in the sysV initscript.
the question will probably pop-up again with systemd though!


 The maintainer scripts should probably reworked a bit,
 but that will be for later I guess.


yup, I'm still head underwater, concentrating on upstream lead :(
and the backlog for debs is still huge, though Laurent's help has made a
big difference in the past couple of years...

cheers,
Arnaud
-- 
Linux / Unix / Opensource Engineering Expert - Eaton -
http://opensource.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.fr

Bug#664027: O: coherence -- Python UPnP framework

[Arnaud Quette]

Package: wnpp
Severity: normal
Owner: Debian QA Group packa...@qa.debian.org

Hi!

Since I don't use it myself, and I currently have less (no) time for debian
due to policy changes at Eaton, coherence is up for adoption.

cheers,
Arnaud
-- 
Linux / Unix / Opensource Engineering Expert - Eaton -
http://opensource.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.fr

Bug#677143: nut-server not starting properly before upsmon

[Arnaud Quette]

2012/8/11 Laurent Bigonville bi...@debian.org

 retitle 677143 nut-server: driver not always started when using systemd
 thanks

 Hello,

 Actually it seems that  it's the driver which is not started properly:

 Aug 11 17:37:39 fornost upsd[1967]: Can't connect to UPS [ellipse]
 (usbhid-ups-ellipse): No such file or directory

 Is it possible that /dev/bus/usb/ is not fully populated. This seems
 random on my system, so I guess there is still a race somewhere.


a classic issue with USB devs, and a thing I've never had time to check
toroughly, is our udev calls in postinst WRT the device being already
plugged in.
in that case, I'm not sure the perms are refreshed, without unplugging /
plugging back the UPS USB cord...
and as you told, a race in systemd is still possible.

cheers,
Arnaud
-- 
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.fr

Bug#677054: nut-client: prompting due to modified conffiles which were not modified by the user

[Arnaud Quette]

2012/8/9 Laurent Bigonville bi...@debian.org

 Hi,


Hi Laurent,

It seems that the issue is that the nut-server postinst script in the
 version currently in squeeze is modifying the freshly
 installed /etc/nut/nut.conf (to remove the white spaces around the
 equal sign) which means that md5 doesn't match anymore.


right, this was an upstream issue.


 I'm not too sure how this could be fixed.


the best would be to patch nut.conf to have spaces already removed.
I don't see anything else.

cheers,
Arnaud
-- 
Linux / Unix / Opensource Engineering Expert - Eaton -
http://opensource.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.fr

Bug#677054: nut-client: prompting due to modified conffiles which were not modified by the user

[Arnaud Quette]

2012/8/9 Laurent Bigonville bi...@debian.org

 Le Thu, 9 Aug 2012 16:54:33 +0200,
 Arnaud Quette aquette@gmail.com a écrit :

  2012/8/9 Laurent Bigonville bi...@debian.org
 
   Hi,
  
 
  Hi Laurent,
 
  It seems that the issue is that the nut-server postinst script in the
   version currently in squeeze is modifying the freshly
   installed /etc/nut/nut.conf (to remove the white spaces around the
   equal sign) which means that md5 doesn't match anymore.
  
 
  right, this was an upstream issue.
 
 
   I'm not too sure how this could be fixed.
  
 
  the best would be to patch nut.conf to have spaces already removed.
  I don't see anything else.

 In the current version in wheezy/sid, this is already done. Should we
 do this also in stable to limit the number of people impacted by this?


that would probably be better. But I'll (once more) leave it up to you, if
we want to have a solution in a timely fashion.

Thanks again Laurent for all your help on packaging...

cheers,
Arnaud
-- 
Linux / Unix / Opensource Engineering Expert - Eaton -
http://opensource.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.fr

Bug#679513: upsmon sends invalid commands to upssched

[Arnaud Quette]

tags 679513 + fixed-upstream
Thanks

Hi Vladimir,

2012/6/29 Vladimir Volovich vladimir.volov...@gmail.com

 Package: nut-client
 Version: 2.6.4-1
 Severity: important

 when an onbatt event occurs, I see messages such as the following in
 /var/log/daemon.log:

 Jun 29 13:41:39 netadm5 upsmon[3752]: UPS ippon@127.0.0.1 on battery
 Jun 29 13:41:39 netadm5 upssched[30216]: Timer daemon started
 Jun 29 13:41:39 netadm5 upssched[30216]: Unknown command on socket:
 Jun 29 13:41:39 netadm5 upssched[30216]: arg 0: 15START
 Jun 29 13:41:39 netadm5 upssched[30216]: arg 1: onbatt
 Jun 29 13:41:39 netadm5 upssched[30216]: arg 2: 15
 Jun 29 13:41:39 netadm5 upssched[30215]: read confirmation got [ERR
 UNKNOWN t
 15]
 Jun 29 13:41:39 netadm5 upssched[30216]: Unknown command on socket:
 (...)


this is an upstream regression, that has been fixed in NUT trunk r3670:
http://trac.networkupstools.org/projects/nut/changeset/3670

I'm currently preparing the upstream 2.6.5 release, and will upload debs
next.
While waiting, you may use an earlier version of the upssched binary.

cheers,
Arnaud
-- 
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.fr

Bug#679450: nut: Please add systemd unit files

[Arnaud Quette]

Hi Laurent

2012/6/28 Laurent Bigonville bi...@debian.org

 Package: nut
 Version: 2.6.4-1
 Severity: wishlist

 Hi,

 It would be nice if nut has systemd unit files.


NUT upstream provides systemd support since 2.6.2.
systemd support is tested automatically at build time, not install time.

I've not followed the recent evolution on the Debian front, but are we
switching to systemd?
Should we install services files beside or instead of sysV ones?

Note that I'm currently preparing the upstream 2.6.5 release, so debs
update will follow.

cheers,
Arnaud
-- 
Linux / Unix / Opensource Engineering Expert - Eaton -
http://opensource.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.fr
--
Conseiller Municipal - Saint Bernard du Touvet

Bug#671444: [Nut-upsuser] Bug#671444: LiebertPSP

[Arnaud Quette]

2012/6/10 Tim Gould tgo...@reverb.com.au

 I upgraded to trunk (3652) - it worked, but again with the seemingly
 spurious RB during DISCHRG.


more than a upsd trace, we need usbhid-ups (-D) to be able to see
what's going on...
Ie, is the device actually reporting RB
(UPS.PowerSummary.PresentStatus.NeedReplacement == 1...) or not.


 -DDD output attached. RB turns up just before battery.charge.low is
 reached (around 1551 sec), at the same time LB turns up too.

 Once a slave client (on the same UPS) shuts down battery.charge goes back
 up above battery.charge.low, so LB goes away, but RB stays.

 I didn't have upsmon running on this host so it ran until the battery was
 depleted rather than shutting down.


the above use case should not be a problem, since an initiated shutdown
(master + slave) will go to the completion.
a variation, where the above result is desired, is load shedding, where you
want to shutdown non critical loads, to get more runtime for the critical
ones...


 Hope this helps, thanks, Tim.


it indeed helps, thanks Tim.

cheers,
Arnaud
-- 
Linux / Unix / Opensource Engineering Expert - Eaton -
http://opensource.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr

Bug#676846: Missing headers in libipmimonitoring-dev, needed by nut-ipmi

[Arnaud Quette]

Package: libipmimonitoring-dev
Version: 1.1.5-1
Tags: patch

as per source, libipmimonitoring/Makefile.am:

include_HEADERS = ipmi_monitoring.h ipmi_monitoring_bitmasks.h
ipmi_monitoring_offsets.h

This means that these 3 files must be installed, in order for
applications using this lib to build.
A patch is attached.

Note that I have a new package upload (nut-ipmi) that is blocked
because of the missing ipmi_monitoring_bitmasks.h.
Thanks for your help.

cheers,
Arnaud
-- 
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr


libipmonitoring-bitmask.diff
Description: Binary data

Bug#565751: wmnut: no withdrawn mode

[Arnaud Quette]

salut Manu

 On 01/06/12 23:35, Arnaud Quette wrote:
 I've finally setup a git repo to ease this fix, and further maintenance:
 https://github.com/aquette/wmnut

 That seems to have fixed it. Thanks!

great, thanks for the feedback ;-)
I'm going to release 0.64 and upload it.

cheers,
Arnaud
-- 
Linux / Unix / Opensource Engineering Expert - Eaton -
http://opensource.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr



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

Bug#565751: wmnut: no withdrawn mode

[Arnaud Quette]

salut,

 Sorry for resurrecting an old bug report like this, but I am currently
 having the same problem with WindowMaker 0.95.3. Both WindowMaker and
 WMNut are from Debian Sid on AMD64.

you did well.
it's part of the things that get forgotten, due to an overwhelmed backlog...

I've refreshed a bit WMnut a month ago (v 0.63): http://wmnut.mgeops.org/

could you please quickly check how it behaves and report back?

cheers,
Arnaud
-- 
Linux / Unix / Opensource Engineering Expert - Eaton -
http://opensource.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr



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

Bug#660072: [nut] Invalid udev rules prevent operation of nut

[Arnaud Quette]

2012/2/16 Roman Mamedov r...@romanrm.ru:
 On Thu, 16 Feb 2012 13:10:41 +0100
 Arnaud Quette aquette@gmail.com wrote:

 Hi Roman,

 thanks for your report.

 2012/2/16 Roman Mamedov r...@romanrm.ru:
  Package: nut
  Version: 2.6.3-1
  Severity: important
 
  nut is completely broken on my system since quite some time ago.
 
  $ dpkg -S /etc/udev/rules.d/52-nut-usbups.rules
  nut: /etc/udev/rules.d/52-nut-usbups.rules
 
  $ debsums -e  nut
  /etc/udev/rules.d/52-nut-usbups.rules                                      
     OK

 this file is not anymore part of the NUT packages since 

 Are you sure about that?

 $ dpkg -l nut
 Desired=Unknown/Install/Remove/Purge/Hold
 | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
 |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
 ||/ Name               Version            Description
 +++-==-==-
 ii  nut                2.6.3-1            network UPS tools - metapackage

 $ dpkg -L nut
 /.
 /usr
 /usr/share
 /usr/share/doc
 /usr/share/doc/nut
 /usr/share/doc/nut/config-notes.txt.gz
 /usr/share/doc/nut/scheduling.txt.gz
 /usr/share/doc/nut/UPGRADING.gz
 /usr/share/doc/nut/security.txt.gz
 /usr/share/doc/nut/AUTHORS.gz
 /usr/share/doc/nut/documentation.txt
 /usr/share/doc/nut/support.txt
 /usr/share/doc/nut/MAINTAINERS
 /usr/share/doc/nut/changelog.Debian.gz
 /usr/share/doc/nut/acknowledgements.txt.gz
 /usr/share/doc/nut/copyright
 /usr/share/doc/nut/changelog.gz
 /usr/share/doc/nut/FAQ.txt.gz
 /usr/share/doc/nut/download.txt.gz
 /usr/share/doc/nut/nut-names.txt.gz
 /usr/share/doc/nut/features.txt.gz
 /usr/share/doc/nut/TODO.gz
 /usr/share/doc/nut/NEWS.gz
 /usr/share/doc/nut/user-manual.txt
 /usr/share/doc/nut/packager-guide.txt.gz
 /usr/share/doc/nut/README.gz
 /usr/share/doc/nut/outlets.txt
 /usr/share/doc/nut/history.txt.gz
 /etc/nut/upssched.conf.sample
 /etc/nut/upsmon.conf.sample
 /etc/nut/upsd.users.sample
 /etc/nut/ups.conf.sample
 /etc/nut/upsd.conf.sample
 /etc/udev/rules.d/52-nut-usbups.rules   
 ---

 the new one is located in /lib/udev, and has been updated to match the
 latest udev (Ie, there is no BUS reference anymore).
 (...)

here is what I have with a fresh install:

$ dpkg -l nut
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version
   Description
+++-==-==-
ii  nut2.6.3-1
   network UPS tools - metapackage

$ dpkg -L nut
/.
/usr
/usr/share
/usr/share/doc
/usr/share/doc/nut
/usr/share/doc/nut/config-notes.txt.gz
/usr/share/doc/nut/scheduling.txt.gz
/usr/share/doc/nut/UPGRADING.gz
/usr/share/doc/nut/security.txt.gz
/usr/share/doc/nut/AUTHORS.gz
/usr/share/doc/nut/documentation.txt
/usr/share/doc/nut/support.txt
/usr/share/doc/nut/MAINTAINERS
/usr/share/doc/nut/changelog.Debian.gz
/usr/share/doc/nut/acknowledgements.txt.gz
/usr/share/doc/nut/copyright
/usr/share/doc/nut/changelog.gz
/usr/share/doc/nut/FAQ.txt.gz
/usr/share/doc/nut/download.txt.gz
/usr/share/doc/nut/nut-names.txt.gz
/usr/share/doc/nut/features.txt.gz
/usr/share/doc/nut/TODO.gz
/usr/share/doc/nut/NEWS.gz
/usr/share/doc/nut/user-manual.txt
/usr/share/doc/nut/packager-guide.txt.gz
/usr/share/doc/nut/README.gz
/usr/share/doc/nut/outlets.txt
/usr/share/doc/nut/history.txt.gz

so, the same as yours, apart from
/etc/udev/rules.d/52-nut-usbups.rules which is now part of
nut-server and located in /lib/udev/rules.d/52-nut-usbups.rules

 there may be something wrong in the upgrade path, following the
 various and invasive updates on the packages.

yup, I'll be checking this with the current 2.6.4 update underway.

cheers,
Arnaud
-- 
Linux / Unix / Opensource Engineering Expert - Eaton -
http://opensource.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr



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

Bug#565751: wmnut: no withdrawn mode

[Arnaud Quette]

2012/6/1 Manu Benoît tsee...@nocternity.net:
 On 01/06/12 16:48, Manu Benoît wrote:
 I'm going to try moving my current GNUstep directory out of the way and
 report back on that.

 That had absolutely no effect.

I've finally setup a git repo to ease this fix, and further maintenance:
https://github.com/aquette/wmnut

I've already committed a first thing, that I'd like you to test:
https://github.com/aquette/wmnut/commit/15c8dd9536c80c28cf42c55eb51b436c3b37701f

could you please also confirm that wmtime behaves as expected?

cheers,
Arno



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

Bug#675203: [CVE-2012-2944] upsd can be remotely crashed

[Arnaud Quette]

Package: nut
Severity: critical
Tags: security patch

The following potential vulnerability had been reported against NUT
(Network UPS Tools):
https://alioth.debian.org/tracker/index.php?func=detailaid=313636group_id=30602atid=411542

The patch has already been committed upstream (development version),
and include more details on the issue:
http://trac.networkupstools.org/projects/nut/changeset/3633

It will be available in 2.6.4, which will be released by the end of the week.
This will fix Sid and Testing.

But Stable is still exposed (NUT 2.4.3). I'm currently preparing an
upload to fix it (2.4.3-1.1squeeze2).

Please use CVE-2012-2944 for this issue.
This CVE is not yet official, but will be on Friday, June Arst 00:00:00 UTC.

cheers,
Arnaud
--
Linux / Unix Expert RD - Eaton - http://powerquality.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/



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

Bug#671444: [Nut-upsuser] LiebertPSP

[Arnaud Quette]

2012/5/10 Charles Lepple clep...@gmail.com:
 On May 10, 2012, at 4:38 AM, Arnaud Quette wrote:

 2012/5/10 Charles Lepple clep...@gmail.com:
 On May 9, 2012, at 11:27 AM, Arnaud Quette wrote:

 this thread has just popped again, but on the Debian side this time:
 http://bugs.debian.org/671444

 what's exactly the situation of fixes WRT issues?
 the last mail I have on this thread is attached below...

 Attached is a patch corresponding to the following branch:

   https://github.com/clepple/nut/tree/git-LiebertPSP-scalefactor

 At this point, it is probably safe to merge.

 it applies fine on the trunk.
 should I go ahead and merge it?

 Sure,

merged to the Subversion trunk, r3607

 but is it possible to build a .deb for Alastair to test, just to make sure 
 we're fixing the same problem? (I'm not sure if Debian has something like 
 Ubuntu's PPA system.)

I'm already lagging on the mainstream (Debian), with 2.6.3 updates
stagging on git for 3 months...
so I won't commit on test packages.

 Aside: it is annoying that with a 16-bit field for the USB PID, companies 
 insist on reusing the VID:PID combinations for drastically different firmware.

yup, this is also the situation here at Eaton, and I'm desperately
fighting against that.

 also, does it fix all the known issues related to this scaling factor?

 The two potential remaining problems are with ups.load and the RB flag, but 
 they are not as critical as the OB/LB flags.

 It does not, however, change the subdriver to liebert-hid.

 I'm not sure to get all the whizzbang that may hide behind this comment ;-)
 AFAIK, liebert-hid seems to be for Liebert OEM manufactured by
 Phoenixtec with a limited set of data.
 while belkin-hid has a more advanced approach.
 so it's fine as you did. the problem of subdriver naming is something
 else, that will never be able to completely address due to mergers,
 OEM, ...

 In this message, Alastair cited Pier's patch which changes the subdriver for 
 10af:0001 from belkin-hid to liebert-hid. Due to the way that we match the 
 HID usages, we probably could have put the scale fixes in the liebert-hid 
 subdriver instead, but I agree that belkin-hid is probably the right mapping 
 under the hood.

we'll at least have a round with the Belkin mapping, which seems fine.
if there are issue, we'll see how we can improve things.

cheers,
Arnaud
-- 
Linux / Unix Expert RD - Eaton - http://powerquality.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/



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

Bug#671444: [Nut-upsuser] Bug#671444: LiebertPSP

[Arnaud Quette]

Hi Tim,

2012/5/11 Tim Gould tgo...@reverb.com.au:
 FWIW I've had this running just fine since my earlier posts. Several power 
 outages have been dealt with perfectly.

 I haven't had the time to set up and test debug logs around RB but if this is 
 the sticking point I'll try harder to find that time :)

 I'm happy to pull a fresh version and test.

thanks for your feedback.
As told in my separate answer, I've just committed Charles' patch to
the trunk (r3607).
So if you can do some testing, especially on LB/RB, I would be grateful.

cheers,
Arnaud
-- 
Linux / Unix Expert RD - Eaton - http://powerquality.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/


 On 10/05/2012, at 21:58 , Charles Lepple wrote:

 On May 10, 2012, at 4:38 AM, Arnaud Quette wrote:

 2012/5/10 Charles Lepple clep...@gmail.com:
 On May 9, 2012, at 11:27 AM, Arnaud Quette wrote:

 this thread has just popped again, but on the Debian side this time:
 http://bugs.debian.org/671444

 what's exactly the situation of fixes WRT issues?
 the last mail I have on this thread is attached below...

 Attached is a patch corresponding to the following branch:

  https://github.com/clepple/nut/tree/git-LiebertPSP-scalefactor

 At this point, it is probably safe to merge.

 it applies fine on the trunk.
 should I go ahead and merge it?

 Sure, but is it possible to build a .deb for Alastair to test, just to make 
 sure we're fixing the same problem? (I'm not sure if Debian has something 
 like Ubuntu's PPA system.)

 Aside: it is annoying that with a 16-bit field for the USB PID, companies 
 insist on reusing the VID:PID combinations for drastically different 
 firmware.

 also, does it fix all the known issues related to this scaling factor?

 The two potential remaining problems are with ups.load and the RB flag, but 
 they are not as critical as the OB/LB flags.

 It does not, however, change the subdriver to liebert-hid.

 I'm not sure to get all the whizzbang that may hide behind this comment ;-)
 AFAIK, liebert-hid seems to be for Liebert OEM manufactured by
 Phoenixtec with a limited set of data.
 while belkin-hid has a more advanced approach.
 so it's fine as you did. the problem of subdriver naming is something
 else, that will never be able to completely address due to mergers,
 OEM, ...

 In this message, Alastair cited Pier's patch which changes the subdriver for 
 10af:0001 from belkin-hid to liebert-hid. Due to the way that we match the 
 HID usages, we probably could have put the scale fixes in the liebert-hid 
 subdriver instead, but I agree that belkin-hid is probably the right mapping 
 under the hood.

 --
 Charles Lepple
 clepple@gmail



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

Bug#671444: [Nut-upsuser] LiebertPSP

[Arnaud Quette]

2012/5/10 Charles Lepple clep...@gmail.com:
 On May 9, 2012, at 11:27 AM, Arnaud Quette wrote:

 this thread has just popped again, but on the Debian side this time:
 http://bugs.debian.org/671444

 what's exactly the situation of fixes WRT issues?
 the last mail I have on this thread is attached below...

 Attached is a patch corresponding to the following branch:

   https://github.com/clepple/nut/tree/git-LiebertPSP-scalefactor

 At this point, it is probably safe to merge.

it applies fine on the trunk.
should I go ahead and merge it?

also, does it fix all the known issues related to this scaling factor?

 It does not, however, change the subdriver to liebert-hid.

I'm not sure to get all the whizzbang that may hide behind this comment ;-)
AFAIK, liebert-hid seems to be for Liebert OEM manufactured by
Phoenixtec with a limited set of data.
while belkin-hid has a more advanced approach.
so it's fine as you did. the problem of subdriver naming is something
else, that will never be able to completely address due to mergers,
OEM, ...

cheers,
Arnaud
-- 
Linux / Unix Expert RD - Eaton - http://powerquality.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/



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

Bug#671308: [PATCH] wmnut: Helping to update to packaging format 3.0

[Arnaud Quette]

Hi Jari,

2012/5/5 jaalto jari.aa...@cante.net:
 On 2012-05-03 13:30, Arnaud Quette wrote:
 |     http://wiki.debian.org/Projects/DebSrc3.0
 | 
 |  I had some free time; see attached patch to migrate to new package
 |  format.
 |
 | thanks, your contrib here is much appreciated.
 | I'm indeed currently in the depth of completing 2.6.3 packages, and
 | most of all, 2.6.4 upstream + preparation for 2.8.0
 |
 | to make things easier, I can release a new wmnut upstream...

 That's good to hear.

I would appreciate a dedicated patch if you can.
I'll otherwise check to apply the one you posted, but it needs some
cutting before...

 | beside from this, note that I'm still looking for a co-maint to help
 | me in NUT related packages maintenance. This would allow me to
 | concentrate even more on upstream developments.  would you be
 | interested in?

 I've been helping with other package maintainers with 3.0 migration
 like this before. If I can be of any help, like adjusting the patch to
 your latest development sources, let me know. As for involving more,
 I'm Unfortunately I'm also as busy as you elsewhere with other duties.

understood.
I'm always asking, just in case.

cheers,
Arnaud
-- 
Linux / Unix Expert RD - Eaton - http://powerquality.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/



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

Bug#671308: [PATCH] wmnut: Helping to update to packaging format 3.0

[Arnaud Quette]

Hi Jari,

small update: I've taken a few minutes to check the patch stack, do
some cleanup and release WMNut 0.63...
It's available on wmnut.mgeops.org, as usual...

cheers,
Arnaud

2012/5/10 Arnaud Quette aquette@gmail.com:
 Hi Jari,

 2012/5/5 jaalto jari.aa...@cante.net:
 On 2012-05-03 13:30, Arnaud Quette wrote:
 |     http://wiki.debian.org/Projects/DebSrc3.0
 | 
 |  I had some free time; see attached patch to migrate to new package
 |  format.
 |
 | thanks, your contrib here is much appreciated.
 | I'm indeed currently in the depth of completing 2.6.3 packages, and
 | most of all, 2.6.4 upstream + preparation for 2.8.0
 |
 | to make things easier, I can release a new wmnut upstream...

 That's good to hear.

 I would appreciate a dedicated patch if you can.
 I'll otherwise check to apply the one you posted, but it needs some
 cutting before...

 | beside from this, note that I'm still looking for a co-maint to help
 | me in NUT related packages maintenance. This would allow me to
 | concentrate even more on upstream developments.  would you be
 | interested in?

 I've been helping with other package maintainers with 3.0 migration
 like this before. If I can be of any help, like adjusting the patch to
 your latest development sources, let me know. As for involving more,
 I'm Unfortunately I'm also as busy as you elsewhere with other duties.

 understood.
 I'm always asking, just in case.

 cheers,
 Arnaud
 --
 Linux / Unix Expert RD - Eaton - http://powerquality.eaton.com
 Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
 Debian Developer - http://www.debian.org
 Free Software Developer - http://arnaud.quette.free.fr/



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

Bug#671444: [Nut-upsuser] LiebertPSP

[Arnaud Quette]

Charles, Tim et all,

this thread has just popped again, but on the Debian side this time:
http://bugs.debian.org/671444

what's exactly the situation of fixes WRT issues?
I can't find an actual conclusion, and the last mail I have on this
thread is attached below...

cheers,
Arnaud

2012/1/19 Charles Lepple clep...@gmail.com:
 On Jan 14, 2012, at 7:38 AM, Tim Gould wrote:

 Shutdown test was successful, including a slave client. They both shut down 
 cleanly starting at 38% as configured below.

 Excellent!

 Only issue was that as it hit this threshold, it also reported Replace 
 Battery (ups.status had RB) , and upsmon[3265]: UPS shed@localhost battery 
 needs to be replaced appeared in syslog.

 We would need that portion of the debug log to confirm what is being sent 
 back from the UPS, but if it works the rest of the time, it might just be a 
 spurious battery status bit. I would think that wouldn't be updated by the 
 UPS except after a deep discharge test, but it's hard to say.

 After the systems were powered on and mains restored, this went away.

 If ups.load is supposed to be Watts then according to my power meter it 
 probably needs an extra zero at the end.

 ups.load should be percent rated capacity.

 --
 Charles Lepple
 clepple@gmail



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

Bug#671444: [Nut-upsuser] LiebertPSP

[Arnaud Quette]

Charles, Tim et all,

this thread has just popped again, but on the Debian side this time:
http://bugs.debian.org/671444

what's exactly the situation of fixes WRT issues?
the last mail I have on this thread is attached below...

cheers,
Arnaud

2012/1/19 Charles Lepple clep...@gmail.com:
 On Jan 14, 2012, at 7:38 AM, Tim Gould wrote:

 Shutdown test was successful, including a slave client. They both shut down 
 cleanly starting at 38% as configured below.

 Excellent!

 Only issue was that as it hit this threshold, it also reported Replace 
 Battery (ups.status had RB) , and upsmon[3265]: UPS shed@localhost battery 
 needs to be replaced appeared in syslog.

 We would need that portion of the debug log to confirm what is being sent 
 back from the UPS, but if it works the rest of the time, it might just be a 
 spurious battery status bit. I would think that wouldn't be updated by the 
 UPS except after a deep discharge test, but it's hard to say.

 After the systems were powered on and mains restored, this went away.

 If ups.load is supposed to be Watts then according to my power meter it 
 probably needs an extra zero at the end.

 ups.load should be percent rated capacity.

 --
 Charles Lepple
 clepple@gmail



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

Bug#671308: [PATCH] wmnut: Helping to update to packaging format 3.0

[Arnaud Quette]

2012/5/3  jari.aa...@cante.net:
 Package: wmnut
 Severity: wishlist
 Tags: patch

 Hi,

Hi Jari,

 The dpatch patch management system has been deprecated for some time. The
 Lintian currently flags use of dpatch packages as an error. The new 3.0
 packaging format is an improved version which, among other things, contains
 patch management built-in. For more information, see:

    http://wiki.debian.org/Projects/DebSrc3.0

 I had some free time; see attached patch to migrate to new package
 format. Note that all files in debian/patches/* are canocalized to
 *.patch.

 Let me know if there is anything that needs adjusting or if it is ok
 to upload this version in a NMU in case you are working on other
 issues needing attention.

thanks, your contrib here is much appreciated.
I'm indeed currently in the depth of completing 2.6.3 packages, and
most of all, 2.6.4 upstream + preparation for 2.8.0

to make things easier, I can release a new wmnut upstream...

beside from this, note that I'm still looking for a co-maint to help
me in NUT related packages maintenance.
this would allow me to concentrate even more on upstream developments.
would you be interested in?

cheers,
Arnaud
-- 
Linux / Unix Expert RD - Eaton - http://powerquality.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/



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

Bug#660072: [nut] Invalid udev rules prevent operation of nut

[Arnaud Quette]

Hi Roman,

thanks for your report.

2012/2/16 Roman Mamedov r...@romanrm.ru:
 Package: nut
 Version: 2.6.3-1
 Severity: important

 nut is completely broken on my system since quite some time ago.

 $ dpkg -S /etc/udev/rules.d/52-nut-usbups.rules
 nut: /etc/udev/rules.d/52-nut-usbups.rules

 $ debsums -e  nut
 /etc/udev/rules.d/52-nut-usbups.rules                                         
 OK

this file is not anymore part of the NUT packages since 
the new one is located in /lib/udev, and has been updated to match the
latest udev (Ie, there is no BUS reference anymore).

 /etc/nut/ups.conf.sample                                                      
 OK
 /etc/nut/upsmon.conf.sample                                                   
 OK
 /etc/nut/upsd.conf.sample                                                     
 OK
 /etc/nut/upssched.conf.sample                                                 
 OK
 /etc/nut/upsd.users.sample                                                    
 OK

 ---

 Feb 16 11:48:33 natsu upsd[5477]: listening on 127.0.0.1 port 3493
 Feb 16 11:48:33 natsu upsd[5477]: listening on ::1 port 3493
 Feb 16 11:48:33 natsu upsd[5477]: Can't connect to UPS [pw800] 
 (blazer_usb-pw800): Permission denied
 Feb 16 11:48:33 natsu upsd[5477]: allowfrom in upsd.users is no longer used
 Feb 16 11:48:33 natsu upsd[5478]: Startup successful
 Feb 16 11:48:33 natsu upsmon[5481]: Startup successful
 Feb 16 11:48:35 natsu udevd[484]: unknown key 'BUS' in 
 /etc/udev/rules.d/52-nut-usbups.rules:6
 Feb 16 11:48:35 natsu udevd[484]: invalid rule 
 '/etc/udev/rules.d/52-nut-usbups.rules:6'
 Feb 16 11:48:35 natsu udevd[484]: unknown key 'SYSFS{idVendor}' in 
 /etc/udev/rules.d/52-nut-usbups.rules:10
 Feb 16 11:48:35 natsu udevd[484]: invalid rule 
 '/etc/udev/rules.d/52-nut-usbups.rules:10'
 ...

could you please send back the following:
- are you on testing or sid?
- which nut version you upgraded from (related to the above question)?
- result of dpkg -l 'nut*'

there may be something wrong in the upgrade path, following the
various and invasive updates on the packages.

cheers,
Arnaud
-- 
Linux / Unix Expert RD - Eaton - http://powerquality.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/



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

Bug#598741: [nut] upsd fails to start on a IPv6 disabled kernel

[Arnaud Quette]

2011/10/13 Arnaud Quette aquette@gmail.com

 Hi Pavel,

 2011/9/26 Arnaud Quette aquette@gmail.com:
  hem, it's better with the actual file.
  attached this time.
 
  cheers,
 
  2011/9/26 Arnaud Quette aquette@gmail.com:
  Hi again Pavel,
 
  I forgot to attach another patch, that allows at least one of the
  default v4 *or* v6 address to work.
  could you please test it and report back?

 have you been able to test the patch?
 I have 2.6.3 scheduled for soon and would appreciate your contrib ;-)


tested on my side and committed to the trunk:
http://anonscm.debian.org/viewvc/nut?view=revisionrevision=3312

cheers,
Arnaud
-- 
Linux / Unix Expert RD - Eaton - http://powerquality.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/

Bug#598741: [nut] upsd fails to start on a IPv6 disabled kernel

[Arnaud Quette]

Hi Pavel,

2011/9/26 Arnaud Quette aquette@gmail.com:
 hem, it's better with the actual file.
 attached this time.

 cheers,

 2011/9/26 Arnaud Quette aquette@gmail.com:
 Hi again Pavel,

 I forgot to attach another patch, that allows at least one of the
 default v4 *or* v6 address to work.
 could you please test it and report back?

have you been able to test the patch?
I have 2.6.3 scheduled for soon and would appreciate your contrib ;-)

cheers,
Arnaud



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

Bug#633756: warning: variable set but not used [-Wunused-but-set-variable]

[Arnaud Quette]

Hi Regid,

2011/7/13 Regid Ichira:
  I noticed another 13 instances of that warning:
 belkinunv.c:1242:9: warning: variable 'r'
 etapro.c:216:7: warning: variable 'status'
 gamatronic.c:251:17: warning: variable 'e'
 isbmex.c:326:9: warning: variable 'ret'
 metasys.c:99:6: warning: variable 'i'
 mge-shut.c:799:16: warning: variable 'sdata'
 microdowell.c:192:11: warning: variable 'ret'
 libshut.c:681:16: warning: variable 'sdata'
 rhino.c:480:36: warning: variable 'sizes'
 rhino.c:648:20: warning: variable 'mins'
 rhino.c:648:13: warning: variable 'hours'
 solis.c:323:16: warning: variable 'tst'
 solis.c:358:6: warning: variable 'iw'

  Will it help if I will provide a patch for the places that I think I know how
 to eliminate the warning?  I don't use any of those drivers.

sure, it would save a bit more time, that I'm currently lacking.
posting directly (or cc'ing) NUT upsdev mailing would even allow some
other developer(s) to take over checks and application:
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev

thanks for your contribs,
Arnaud
-- 
Linux / Unix Expert RD - Eaton - http://powerquality.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/



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

Bug#640661: Error in udev rules at boot for nut

[Arnaud Quette]

Hi Gabriele,

2011/9/6 Gabriele Vivinetto gabriele.mail...@rvmgroup.it:
 Package: nut
 Version: 2.4.3-1.1squeeze1
 Severity: normal

 At boot I receive the error BUS= will be removed ina future udev version. 
 please use SUBSYSTEM= to match the event device, or SUBSYSTEMS= to match a 
 parent device, in /usr/lib/udev/rules.d/52-nut-usbups.rules:6
 Bug 562064 states that this issue is resolved, but here the message is shown 
 again.

2.4.3 has solved the SYSFS Vs ATTR, while 2.6.0 has solved the BUS Vs SUBSYSTEM.
This is only a warning, though polluting the log.
So I'm closing this report.

Can you please confirm that updating to 2.6.0 has fixed the issue?

cheers,
Arnaud
-- 
Linux / Unix Expert RD - Eaton - http://powerquality.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/



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

Bug#598741: [nut] upsd fails to start on a IPv6 disabled kernel

[Arnaud Quette]

Hi Pavel,

I've just committed (upstream) the below patch.
I'll close this bug when nut-2.6.3 hist unstable.

thanks for your report,
Arnaud
-- 
Linux / Unix Expert RD - Eaton - http://powerquality.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/


-- Forwarded message --
From: Arnaud Quette aque...@alioth.debian.org
Date: 2011/9/26
Subject: [nut-commits] svn commit r3260 - trunk/conf
To: nut-comm...@lists.alioth.debian.org


Author: aquette
Date: Mon Sep 26 19:54:53 2011
New Revision: 3260
URL: http://trac.networkupstools.org/projects/nut/changeset/3260

Log:
Complete LISTEN information, with regard to IP v4 or v6 disabled
kernel (reported by Pavel Zubkou, Debian bug #598741)

Modified:
  trunk/conf/upsd.conf.sample

Modified: trunk/conf/upsd.conf.sample
==
--- trunk/conf/upsd.conf.sample Mon Sep 26 18:34:40 2011        (r3259)
+++ trunk/conf/upsd.conf.sample Mon Sep 26 19:54:53 2011        (r3260)
@@ -3,6 +3,8 @@
 # This file contains access control data, you should keep it secure.
 #
 # It should only be readable by the user that upsd becomes.  See the FAQ.
+#
+# Each entry below provides usage and default value.

 # ===
 # MAXAGE seconds
@@ -27,8 +29,9 @@
 # ===
 # LISTEN address [port]
 # LISTEN 127.0.0.1 3493
+# LISTEN ::1 3493
 #
-# This defaults to the localhost listening address and port 3493.  You
+# This defaults to the localhost listening addresses and port 3493.  You
 # may specify each interface you want upsd to listen on for connections,
 # optionally with a port number.
 #
@@ -36,6 +39,10 @@
 # you don't want upsd to listen to all interfaces (for instance on a
 # firewall, you may not want to listen to the external interface).
 #
+# You may also need this in case of IP v4 or v6 disabled kernel, to
+# restrict listening to the type that is enabled. Otherwise, upsd will
+# fail to start.
+#
 # This will only be read at startup of upsd.  If you make changes here,
 # you'll need to restart upsd, reload will have no effect.



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

Bug#598741: [nut] upsd fails to start on a IPv6 disabled kernel

[Arnaud Quette]

Hi again Pavel,

I forgot to attach another patch, that allows at least one of the
default v4 *or* v6 address to work.
could you please test it and report back?

cheers,
Arnaud



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

Bug#598741: [nut] upsd fails to start on a IPv6 disabled kernel

[Arnaud Quette]

hem, it's better with the actual file.
attached this time.

cheers,

2011/9/26 Arnaud Quette aquette@gmail.com:
 Hi again Pavel,

 I forgot to attach another patch, that allows at least one of the
 default v4 *or* v6 address to work.
 could you please test it and report back?

 cheers,
 Arnaud



upsd-v4orv6.patch
Description: application/mbox

Bug#642789: nut: FTBFS: a2x: ERROR: xsltproc ... returned non-zero exit status 5

[Arnaud Quette]

Hi Monica,

thanks for your report.

2011/9/24 Mònica Ramírez mon...@probeta.net:
 Source: nut
 Version: 2.6.1-2
 Severity: serious
 Tags: wheezy sid
 User: debian...@lists.debian.org
 Usertags: qa-ftbfs-20110923 qa-ftbfs
 Justification: FTBFS on amd64

 Hi,

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

 Relevant part:
 make[3]: Entering directory `/build/nut-XXqT8h/nut-2.6.1/docs/website'
 make[3]: Nothing to be done for `all'.
 make[3]: Leaving directory `/build/nut-XXqT8h/nut-2.6.1/docs/website'
 /usr/bin/a2x  --attribute icons --attribute localdate=`TZ=UTC date 
 +%Y-%m-%d` --attribute localtime=`TZ=UTC date +%H:%M:%S` --attribute 
 iconsdir=./images --attribute=badges --attribute=external_title -a toc -a 
 numbered --destination-dir=. --attribute=chunked_format --format=chunked 
 user-manual.txt
 a2x: ERROR: xsltproc  --stringparam callout.graphics 0 --stringparam 
 navig.graphics 0 --stringparam admon.textlabel 1 --stringparam 
 admon.graphics 0  --stringparam base.dir user-manual.chunked/ 
 /etc/asciidoc/docbook-xsl/chunked.xsl 
 /build/nut-XXqT8h/nut-2.6.1/docs/user-manual.xml returned non-zero exit 
 status 5
 make[2]: *** [user-manual.chunked] Error 1

 The full build log is available from:
   http://people.debian.org/~lucas/logs/2011/09/23/nut_2.6.1-2_lsid64.buildlog

strange, since doc build has been well tested.
I'm currently working on 2.6.2-1.
on this specific topic (doc building), it has a workaround in case
there is no internet connection, which is the only potential issue.
See http://bugs.debian.org/635347

Can you please try this patch, or confirm on your net availability?
If it's not the case (ie you have a net connection), can you set
ASCIIDOC_VERBOSE=-v and relaunch make from the nut/docs dir (or
similar)?

cheers,
Arnaud
-- 
Linux / Unix Expert RD - Eaton - http://powerquality.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/



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

Bug#642789: nut: FTBFS: a2x: ERROR: xsltproc ... returned non-zero exit status 5

[Arnaud Quette]

Hi Monica,

2011/9/25 Mònica Ramírez mon...@probeta.net:
 Hi!

 I'm currently working on 2.6.2-1.
 on this specific topic (doc building), it has a workaround in case
 there is no internet connection, which is the only potential issue.
 See http://bugs.debian.org/635347

 As the above note says:

 ---
 About the archive rebuild: The rebuild was done on about 50 AMD64 nodes
 of the Grid'5000 platform, using a clean chroot.  Internet was not
 accessible from the build systems.
 ---

oh, sorry. Seems I've read too quickly.

 There is no Internet acces in this build test. Probably this is the
 issue. Do you want I merge this bug with #635347?

yes, please.

 Thanks for your work!

thanks for using it and reporting bugs ^_^

cheers,
Arnaud



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

Bug#635508: Update to FreeIPMI 1.0.5

[Arnaud Quette]

2011/7/26 Yaroslav Halchenko deb...@onerussian.com

 Hi Arnaud,


Hi Yaroslav,

unfortunately freeipmi  package is my own shame -- I have not got some
 time to upgrade it to 1.x series although was going to do that in a
 while.  Main problem to deal is smooth upgrades for users since some
 tools names/config files got changed from 0.8 to 1.x so it needs some
 additional care.

 So, I can't promise any timely update, but will try to find some time
 finally to take care about it



ok, thanks a lot.
I do well know what being over busy means, so no problems ;-)
let me know if I can help.


 On Tue, 26 Jul 2011, Arnaud Quette wrote:

 Package: freeipmi
 Version: 0.8.12-3
 Severity: wishlist
 Hi Yaroslav,
 a number of versions have been released (5 not counting the beta)
 since
 0.8.12.
 1.0.5 even adds pkgconfig support.
 moreover, I (as NUT upstream lead) I'm developing power supply unit
 monitoring for NUT, using FreeIPMI, and will need at least 1.0.1.
 please consider updating FreeIPMI in Debian.
 cheers,
 Arnaud
 --
 =--=
 Keep in touch www.onerussian.com
 Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic


cheers,
Arnaud
-- 
Linux / Unix Expert RD - Eaton - http://powerquality.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/

Bug#635508: Update to FreeIPMI 1.0.5

[Arnaud Quette]

2011/7/27 Yaroslav Halchenko deb...@onerussian.com


 On Wed, 27 Jul 2011, Arnaud Quette wrote:
 ok, thanks a lot.
 I do well know what being over busy means, so no problems ;-)
 let me know if I can help.

 well -- you are DD -- I have filed an RFH for freeipmi:

 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=628062

 ;-)  so all doors are open


thanks for pointing.
I'll check, but no promise on my side too (already too much upstream and not
enough time for the DD side...)
but since I've helped Al to improve a few things, I'd like to also see these
landing in Debian...

cheers,
Arnaud
-- 
Linux / Unix Expert RD - Eaton - http://powerquality.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/

Bug#635508: Update to FreeIPMI 1.0.5

[Arnaud Quette]

Package: freeipmi
Version: 0.8.12-3
Severity: wishlist

Hi Yaroslav,

a number of versions have been released (5 not counting the beta) since
0.8.12.
1.0.5 even adds pkgconfig support.
moreover, I (as NUT upstream lead) I'm developing power supply unit
monitoring for NUT, using FreeIPMI, and will need at least 1.0.1.
please consider updating FreeIPMI in Debian.

cheers,
Arnaud
-- 
Linux / Unix Expert RD - Eaton - http://powerquality.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/

Bug#633756: warning: variable set but not used [-Wunused-but-set-variable]

[Arnaud Quette]

tags 633756 + upstream
thanks

Hi Regid

2011/7/13 Regid Ichira regi...@yahoo.com

 Source: nut
 Version: 2.6.1-1
 Severity: normal
 Tags: patch

 bestfcom.c:263:17: warning: variable 'time' set but not used
 [-Wunused-but-set-variable]
 bestfcom.c:263:8: warning: variable 'date' set but not used
 [-Wunused-but-set-variable]

  I don't use this driver.

  The code block in line 139 has other time\|date variables usage.
 I couldn't see where those variables are defined.  There is a comment
 that the author was declined to waste time on their usage.  The
 beginning of the driver states about the derivation process of this
 driver from other drivers.


bestfcom is part of NUT legacy drivers, that are still provided, though may
be not used anymore.
anyway, it can still be useful, and it doesn't harm to distribute a few moer
Kbs.

that being said, I've just applied your patch upstream (r3132).

cheers,
Arnaud
-- 
Linux / Unix Expert RD - Eaton - http://powerquality.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/

Bug#595773: nut: UPS without description may confuse user

[Arnaud Quette]

Hola Noel David,

sorry for the eternity taken to answer!

2010/9/6 Noel David Torres Taño env...@rolamasao.org

 Package: nut
 Version: 2.4.3-1
 Severity: minor


 Configuring a UPS in /etc/ups.conf without a 'desc' causes this:

 # upsc -L
 upsname: unavailable

 I would suggest changing the message from 'unavailable' to 'description
 unavailable', since the former makes the user think that the UPS itself is
 unavailable.


indeed, thanks a lot for your report.
I've just committed a fix to the development version (2991), set for release
next week (2.6.1)...

cheers,
Arnaud
-- 
Linux / Unix Expert RD - Eaton - http://powerquality.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/

Bug#624255: collect: FTBFS: nut dependency error

[Arnaud Quette]

Hi Sebastian and Dominic,

I've  just realised that this mail was blocked in my draft stack :-/
so thanks to Laurent once again.

2011/4/27 Sebastian Harl tok...@debian.org

 reassign 624255 libupsclient1-dev 2.6.0-1
 retitle 624255 libupsclient1-dev: broken .pc file
 severity 624255 serious
 thanks

 Hi,

 Dominic, thanks for reporting this!

 On Tue, Apr 26, 2011 at 11:06:39PM +0100, Dominic Hargreaves wrote:
  Package: collectd

  This package fails to build from source in a clean sid chroot:

  [...]
 
  nut . . . . . . . . . no (dependency error)
 
  configure: error: Some plugins are missing dependencies - see the
 summary above for details

 config.log reveals:

  configure:22249: checking for upscli_connect in -lupsclient
  configure:22274: i486-linux-gnu-gcc -o conftest -Wall -g -O2
 -I/build/dom-collectd_4.10.1-2.1-i386-S9gxuK/collectd-4.10.1/debian/include
 -DLT_LAZY_OR_NOW='RTLD_LAZY|RTLD_GLOBAL' -UCONFIGFILE
 -DCONFIGFILE='/etc/collectd/collectd.conf'@LIBSSL_LDFLAGS@ -L/lib
 -lupsclient   conftest.c -lupsclient  -ldl  5
  i486-linux-gnu-gcc: @LIBSSL_LDFLAGS@: No such file or directory

 This is due to a wrong 'Libs' entry in the libupsclient pkg-config (.pc)
 file: Libs: -L${libdir} -lupsclient @LIBSSL_LDFLAGS@

 collectd determines the linker flags using 'pkg-config --libs
 libupsclient' which obviously returns '@LIBSSL_LDFLAGS@ -L/lib
 -lupsclient'.

 I've reassigned the bug to libupsclient1-dev. I suppose that
 LIBSSL_LDFLAGS has to be replaced with LIBSSL_LIBS in
 lib/libupsclient.pc.in (and lib/libupsclient-config.in).


this is indeed a side effect of a recent fix.
I've fixed the above upstream (r2960), but have not yet had time to get back
on packaging...
@Seb: if you have a bit of time for an NMU

cheers,
Arnaud
-- 
Linux / Unix Expert RD - Eaton - http://powerquality.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/

Bug#616104: Lintian warning: powercom.8: 114: warning [p 2, 2.5i]: can't break line

[Arnaud Quette]

Hi Laurent

2011/3/2 Laurent Bigonville bi...@debian.org

 Package: nut
 Severity: normal
 Version: 2.4.3-1
 Tags: upstream

 Hi,

 Lintian is giving us a warning about a powercom.8 man page

 nut: manpage-has-errors-from-man usr/share/man/man8/powercom.8.gz 114:
 warning [p 2, 2.5i]: can't break line

 I guess this should be fixed upstream


and this has in fact been fixed upstream ;-)
with 2.6.0, manpages (along with docs and website) are now generated using
AsciiDoc, which should have fixed the above situation (I don't recall such
lintian warnings, but you know the quality of this upload!).

this explain why I've merged the doc typo patch, even if its actual use
will be with 2.6.0-2, and the use of Asciidoc to regenerate mans (if
patched) and generate HTML docs.

cheers,
Arnaud

Bug#609597: [Bug 687985] Re: [FTBFS] package 'nut' (2.4.3-1ubuntu5) failed to build on natty

[Arnaud Quette]

2011/1/10 Laurent Bigonville bi...@bigon.be

 I've found the issue.

 Actually the nut_check_*.m4 are setting *_LDFLAGS instead of *_LIBS, and
 due to a toolchain change this become visible (gcc -o testusb testusb.c
 -lusb is working but gcc -o testusb -lusb testusb.c is not working
 anymore)

 Any reason nut is not using PKG_CHECK_MODULE macro?


the most basic ones: lack of time / manpower and low priority task.
until now, the wide availability of the macro was also another, though it
should be good now.
I know that we can ship our own version, but that can lead to other issues.

thanks for your patch Laurent, I've just applied it (r2821).
so it will be available in 2.6.0 (a little bit more retained due to late bug
reports like this one).

cheers,
Arnaud
-- 
Linux / Unix Expert RD - Eaton - http://powerquality.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/

Bug#557178: nut: Perms on /dev/bus/usb/.../... incorrect upon every upgrade - bad interaction with udev?

[Arnaud Quette]

salut Laurent,

2010/12/21 Laurent Bigonville bi...@debian.org

 Le Mon, 20 Dec 2010 21:49:14 +0100,
 Arnaud Quette aquette@gmail.com a écrit :

  Bonjour Laurent

 Salut,

  sorry for the time taken to answer, but I'm currently busy preparing
  NUT 2.6.0 (for the end of the week).

 As debian is in deep freeze I guess that a separate upload to unstable
 should be required to fix this bug, if you want. But I really think that
 this bug should be fixed in squeeze.


indeed, but I'm really running out of time (the team is growing fast, and
we're already working on 2.8 and 3.0 topics).


   your patch seems fine, thanks.
  I've directly committed it upstream (r2759)

 Thanks, I discovered that this was already applied to ubuntu version of
 the package... There are some other patches that ubuntu have applied in
 their package, I guess that somebody should have a look at them (sigh).


I do so from time to time...
most are backports from the trunk, or already applied, apart from
patches/02-fix-trust-pw4130m.dpatch, which is under discussion for
integration

  cheers,
  Arnaud (looking for a NUT co-maintainer...)

 I have unfortunately no UPS at home (the one I've installed was on a
 remote system), so I don't know if I could help.


not a problem at all ;-)
there are 2 options:
- as for other developers, I can provide (through Eaton) a device.
It can also be considered part of the Debian / Eaton partnership or NUT /
Eaton partnership:
http://www.debian.org/partners/
- the dummy-ups driver already allows enough to validate the system and play
with most functions.


 I think the best is to
 open a RFH[0]. Anyway is there any VCS where I can find the debian
 directory?


I've started one, but I'm not sure if it's really in shape:
http://git.debian.org/?p=collab-maint/nut.git;a=summary


 [0] http://www.debian.org/devel/wnpp/


that's also part of my TODO list for (too) long...

cheers,
Arno
-- 
Linux / Unix Expert RD - Eaton - http://powerquality.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/

Bug#557178: nut: Perms on /dev/bus/usb/.../... incorrect upon every upgrade - bad interaction with udev?

[Arnaud Quette]

Bonjour Laurent

sorry for the time taken to answer, but I'm currently busy preparing NUT
2.6.0 (for the end of the week).

2010/12/20 Laurent Bigonville bi...@debian.org

 tag 557178 + patch
 thanks

 Hi,

 I think I've found the problem (not 100% sure this is the right way to
 do but udevadm trigger now set the permissions correctly.

 Please see the attached patch


your patch seems fine, thanks.
I've directly committed it upstream (r2759)

cheers,
Arnaud (looking for a NUT co-maintainer...)
-- 
Linux / Unix Expert RD - Eaton - http://powerquality.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/

Bug#354429: nut spams consoles and system logs with USB UPS

[Arnaud Quette]

Hi

2010/10/17 deb...@proinbox.com

 I don't follow what you're saying, but here's the output of the
 requested command.

 # ps -elf | grep usbhid-ups
 1 S nut   1508 1  0  80   0 -  4159 -  00:45 ?
 00:00:07 /lib/nut/usbhid-ups -a cyberpower
 1 S nut   1677 1  0  80   0 -  4180 -  00:58 ?
 00:00:10 /lib/nut/usbhid-ups -a cyberpower
 1 S nut   1719 1  0  80   0 -  4180 -  01:35 ?
 00:00:06 /lib/nut/usbhid-ups -a cyberpower
 1 S nut   1732 1  0  80   0 -  4180 -  01:35 ?
 00:00:03 /lib/nut/usbhid-ups -a cyberpower
 0 S root  2073  2068  0  80   0 -  1887 -  09:06 pts/0
 00:00:00 grep usbhid-ups


ok, this is confirmed: you have 4 times the usbhid-ups driver running,
instead of only *1*

please kill all usbhid-ups instances (for example using killall usbhid-ups
as root), then launch the only instance you want to see running, using
upsdrvctl start cyberpower (still as root).
then check if you syslog is still spammed.

cheers,
Arnaud
-- 
Linux / Unix Expert RD - Eaton - http://www.eaton.com/mgeops
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/

Bug#354429: nut spams consoles and system logs with USB UPS

[Arnaud Quette]

2010/10/18 debian

 I don't have a killall command, so I look at htop to find the usbhid-ups
 process.
 I see one from nut, sure:
 [trimmed screenshot]
 Being that there are no USB or HID devices attached to the machine, is
 it safe to assume that this is the only process using usbhid-ups already?

 In any case, I just checked syslog  there's no more of the message that
 there was the other day.
 Also when I connect a local terminal, it's ok.


right, the situation is back to normal, and you only have 1 usbhid-ups
driver instance to talk to your device.
so no need to kill anything!


 I don't know what changed between now and then, but it seems to have
 resolved itself.


a reboot?!

cheers,
Arnaud

Bug#354429: nut spams consoles and system logs with USB UPS

[Arnaud Quette]

Hi

2010/10/17 you wrote:

 Debian Squeeze
 2.6.32-5-amd64
 nut 2.4.3-1.1
 CyberPower 625HG UPS via usb
 Dell PowerEdge R210





 When usb.conf is configured to use driver usbhid-ups, and port=auto,
 functions are proper except syslog  local consoles are filled with the
 messages below.

 As mentioned previously, local consoles are rendered useless unless nut
 service is stopped prior to use.
 (By issuing the following command: /etc/init.d/nut stop)





 I cannot set the usb.conf to use driver cyberpower, as it's been
 removed from the package over lack of maintenance support from the
 vendor.

 When I set the usb.conf to use alternate driver powerpanel, and
 port=auto, the service cannot start and returns Unable to open auto: No
 such file or directory error message.


the 2 above drivers are (or were) serial drivers, requiring a serial port
like /dev/ttyS0.
I don't see the link with the present bug! can you please shed some light?


 Excerpt of usbhis-ups errors:

 Oct 17 00:58:42 Planck kernel: [  827.184548] usb 2-1.1: usbfs: process
 1677 (usbhid-ups) did not claim interface 0 before use
 Oct 17 00:58:45 Planck usbhid-ups[1690]: libusb_get_interrupt: error
 submitting URB: Device or resource busy
 Oct 17 00:58:45 Planck kernel: [  830.234307] usb 2-1.1: usbfs: process
 1690 (usbhid-ups) did not claim interface 0 before use
 Oct 17 00:58:45 Planck kernel: [  830.234418] usb 2-1.1: usbfs: process
 1690 (usbhid-ups) did not claim interface 0 before use
 Oct 17 00:58:45 Planck usbhid-ups[1690]: libusb_get_report: error
 sending control message: Device or resource busy
 Oct 17 00:58:45 Planck usbhid-ups[1690]: Got disconnected by another
 driver: Device or resource busy
 Oct 17 00:58:48 Planck usbhid-ups[1677]: libusb_get_interrupt: error
 submitting URB: Device or resource busy
 Oct 17 00:58:48 Planck usbhid-ups[1677]: libusb_get_report: error
 sending control message: Device or resource busy
 Oct 17 00:58:48 Planck usbhid-ups[1677]: Got disconnected by another
 driver: Device or resource busy
 Oct 17 00:58:48 Planck kernel: [  833.177178] usb 2-1.1: usbfs: process
 1677 (usbhid-ups) did not claim interface 0 before use
 Oct 17 00:58:48 Planck kernel: [  833.177289] usb 2-1.1: usbfs: process
 1677 (usbhid-ups) did not claim interface 0 before use



looking at the above, you have a driver fight: you have probably 2
usbhid-ups drivers instances, fighting to get the device connexion. which in
turns generate the above noise in your syslog.

please confirm this by issuing a ps -elf | grep usbhid-ups

cheers
Arno
-- 
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/

Bug#592552: [knutclient] An UPS Load of 0 (zero) causes the Load graph to show up garbled

[Arnaud Quette]

Hi Dan,

2010/8/27 Daniel Prynych

 Hi friends,
 i thing that version 1.0.3 don't have this problem.
 Dan

 P.S. From version 1.0.0 is used new graphics engine.


thanks for this update.

@Roman: can you please log a wishlist update to 1.0.3 bug?

cheers,
Arnaud
-- 
Linux / Unix Expert RD - Eaton - http://www.eaton.com/mgeops
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/

Bug#592552: [knutclient] An UPS Load of 0 (zero) causes the Load graph to show up garbled

[Arnaud Quette]

Hi Dan,

are you aware of the following issue: http://bugs.debian.org/592552
reported through Debian BTS...

cheers,
Arnaud
-- 
Linux / Unix Expert RD - Eaton - http://www.eaton.com/mgeops
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/

Bug#565751: wmnut: no withdrawn mode

[Arnaud Quette]

2010/7/1 Louis-David Mitterrand l...@apartia.fr

 On Thu, Jul 01, 2010 at 12:04:24AM +0200, Arnaud Quette wrote:
 
  I'm now done with it. I've submitted the patch upstream:
  https://bugs.edge.launchpad.net/awn-extras/+bug/600408
 
which dock are you using btw?
  
   It's openbox's builtin dock, mostly wmaker compatible I think.
  
  
   well, afaik, there is no builtin dock in openbox!
   you're probably running tint2 or awn.
   can you please describe your installation, ie if you used a Debian
   derivative or some kind of script.
  
   ultimately, the following files might help:
   /etc/xdg/openbox/autostart.sh
   ~/.config/openbox/autostart.sh
  
   finally, what do you mean by mostly wmaker compatible?
   are you running old school wm apps and which ones?
  
 
  just for fun, I've installed and tried wmclock (an old school WM app),
 which
  as failed the same way.
  most if not all dock' applets use a specific API, which motivated the
 above
  development.

 For info, here are the wm* docklets I use with openbox:

 - wmacpi
 - wmtime
 - wmnd
 - wmweather+
 - wmxmms2
 - wmforkplop
 - wmfsm


in light of the above, some tests and code analysis, you're fully right.
openbox has its own native WindowMaker style dock.
and I've introduced a regression in wmnut by setting the window, icon and WM
name, instead of only the latter for withdrawn mode. These 3 are reserved to
the windowed mode.
And they were causing the forced windowed mode behavior you're
experiencing...

I'll check for the patch and upload, but later.
I'm a bit tired now (just back from a municipal council...)

cheers,
Arno

Bug#565751: wmnut: no withdrawn mode

[Arnaud Quette]

salut,

2010/6/28 Arnaud Quette

 Salut,

 2010/6/28 Louis-David Mitterrand

 On Thu, Jun 24, 2010 at 11:43:54PM +0200, Arnaud Quette wrote:
  Bonsoir Louis-David,

 Salut Arnaud,

  2010/1/18 Louis-David Mitterrand
 
   Package: wmnut
   Version: 0.62-4
   Severity: important
  
   wmnut refuses to integrate into openbox's applet dock with or without
 -w.
  
   It stays windowed.
  
 
  sorry for this late answer, I completely missed your report.
 
  I can confirm this issue, and I've even tried with awn.
  wmnut is an old school dock app. it doesn't support FreeDesktop System
 Tray
  Protocol.
  which means that it won't work with modern docks.
  that's for the bad news.
 
  now, for the good news:
  - you should try NUT Monitor 1.2. it adds a notification icon that fits
  nicely into most Notification Area applets, and is developed by a French
  friend: http://www.lestat.st/informatique/projets/nut-monitor
  - you, probably due to your name, gave me the final reason to test
 openbox
  (+awn) and fix that wmnut mess.
  I will soon check to make a NUT applet to solve that lack.

 That would be great.


 I'm mostly done with one for awn using the existing battery applet ;-)


I'm now done with it. I've submitted the patch upstream:
https://bugs.edge.launchpad.net/awn-extras/+bug/600408

  which dock are you using btw?

 It's openbox's builtin dock, mostly wmaker compatible I think.


 well, afaik, there is no builtin dock in openbox!
 you're probably running tint2 or awn.
 can you please describe your installation, ie if you used a Debian
 derivative or some kind of script.

 ultimately, the following files might help:
 /etc/xdg/openbox/autostart.sh
 ~/.config/openbox/autostart.sh

 finally, what do you mean by mostly wmaker compatible?
 are you running old school wm apps and which ones?


just for fun, I've installed and tried wmclock (an old school WM app), which
as failed the same way.
most if not all dock' applets use a specific API, which motivated the above
development.

cheers,
Arnaud

Bug#565751: wmnut: no withdrawn mode

[Arnaud Quette]

Salut,

2010/6/28 Louis-David Mitterrand l...@apartia.fr

 On Thu, Jun 24, 2010 at 11:43:54PM +0200, Arnaud Quette wrote:
  Bonsoir Louis-David,

 Salut Arnaud,

  2010/1/18 Louis-David Mitterrand
 
   Package: wmnut
   Version: 0.62-4
   Severity: important
  
   wmnut refuses to integrate into openbox's applet dock with or without
 -w.
  
   It stays windowed.
  
 
  sorry for this late answer, I completely missed your report.
 
  I can confirm this issue, and I've even tried with awn.
  wmnut is an old school dock app. it doesn't support FreeDesktop System
 Tray
  Protocol.
  which means that it won't work with modern docks.
  that's for the bad news.
 
  now, for the good news:
  - you should try NUT Monitor 1.2. it adds a notification icon that fits
  nicely into most Notification Area applets, and is developed by a French
  friend: http://www.lestat.st/informatique/projets/nut-monitor
  - you, probably due to your name, gave me the final reason to test
 openbox
  (+awn) and fix that wmnut mess.
  I will soon check to make a NUT applet to solve that lack.

 That would be great.


I'm mostly done with one for awn using the existing battery applet ;-)

 which dock are you using btw?

 It's openbox's builtin dock, mostly wmaker compatible I think.


well, afaik, there is no builtin dock in openbox!
you're probably running tint2 or awn.
can you please describe your installation, ie if you used a Debian
derivative or some kind of script.

ultimately, the following files might help:
/etc/xdg/openbox/autostart.sh
~/.config/openbox/autostart.sh

finally, what do you mean by mostly wmaker compatible?
are you running old school wm apps and which ones?

cheers,
Arnaud

Bug#565751: wmnut: no withdrawn mode

[Arnaud Quette]

Bonsoir Louis-David,

2010/1/18 Louis-David Mitterrand

 Package: wmnut
 Version: 0.62-4
 Severity: important

 wmnut refuses to integrate into openbox's applet dock with or without -w.

 It stays windowed.


sorry for this late answer, I completely missed your report.

I can confirm this issue, and I've even tried with awn.
wmnut is an old school dock app. it doesn't support FreeDesktop System Tray
Protocol.
which means that it won't work with modern docks.
that's for the bad news.

now, for the good news:
- you should try NUT Monitor 1.2. it adds a notification icon that fits
nicely into most Notification Area applets, and is developed by a French
friend: http://www.lestat.st/informatique/projets/nut-monitor
- you, probably due to your name, gave me the final reason to test openbox
(+awn) and fix that wmnut mess.
I will soon check to make a NUT applet to solve that lack.

which dock are you using btw?

cheers,
Arnaud
-- 
Linux / Unix Expert RD - Eaton - http://www.eaton.com/mgeops
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/

Bug#533169: [Nut-upsdev] nut: megatec_usb shows error ser_send_pace: Device detached on periodically checks

[Arnaud Quette]

2010/2/26 Alexander Gordeev:
 On Thu, 25 Feb 2010 22:14:29 +0100
 Arnaud Quette wrote:

 Hi Alexander and Alexey,

 2009/6/18 Alexander Gordeev:
  Hi Alexey,
 
  Please post the output of 'lsusb' and
  'megatec_usb -a sven_625 -u nut -D'.

 any news on this bug?

 Alexey: have you tried the blazer_usb driver?
 I would be interested in the output, though I doubt the results will
 be different.

 Alexander: can you please produce a patch for megatec_usb (and
 preferably for blazer_usb) to ignore error -5 for testing?

 Well, I agree with Arjen. It's a bit too soon.

ok, please just remember to take care of this bug...

 BTW maybe we should somehow mark megatec_usb obsoleted and/or remove it?

it's right that we have not made note of this in the UPGRADING and/or
NEWS file...

cheers,
Arnaud



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

Bug#533169: [Nut-upsdev] nut: megatec_usb shows error ser_send_pace: Device detached on periodically checks

[Arnaud Quette]

Hi Alexander and Alexey,

2009/6/18 Alexander Gordeev:
 Hi Alexey,

 Please post the output of 'lsusb' and
 'megatec_usb -a sven_625 -u nut -D'.

any news on this bug?

Alexey: have you tried the blazer_usb driver?
I would be interested in the output, though I doubt the results will
be different.

Alexander: can you please produce a patch for megatec_usb (and
preferably for blazer_usb) to ignore error -5 for testing?

cheers,
Arnaud



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

Bug#526811: ACL, ACCEPT, REJECT no longer accepted [needs documenting]

[Arnaud Quette]

Hi Anthony,

2009/5/3 Anthony DeRobertis anth...@derobert.net

 Package: nut
 Version: 2.4.1-2
 Severity: normal

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 May  3 13:33:58 Feynman upsd[28491]: ACL in upsd.conf is no longer
 supported - switch to LISTEN
 May  3 13:33:58 Feynman last message repeated 3 times
 May  3 13:33:58 Feynman upsd[28491]: ACCEPT in upsd.conf is no longer
 supported - switch to LISTEN
 May  3 13:33:58 Feynman last message repeated 2 times
 May  3 13:33:58 Feynman upsd[28491]: REJECT in upsd.conf is no longer
 supported - switch to LISTEN

 etc.

 I don't see anything in /usr/share/doc/nut/UPGRADING.gz nor was there a
 news entry for apt-listchanges:
 (...)


ooch, how did we miss that! thanks for pointing it.
I've just fixed it in the development tree.
2.4.2 will be out very soon now.

cheers,
Arnaud

Bug#531220: nut: diff for NMU version 2.4.1-3.2

[Arnaud Quette]

Hi Stefano,

2009/11/26 Stefano Zacchiroli:
 tags 531220 + patch pending
 thanks

 Dear maintainer,

 I've prepared an NMU for nut (versioned as 2.4.1-3.2) and uploaded it to
 DELAYED/2, according to devref §5.11.1. The patch is based on
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=531220#35 , but is a
 bit more permissive about placement of MODE= in nut.conf (still avoid
 acting on MODE reported in the descriptive comment).

 Hope this helps,

thanks a lot, it indeed helps a lot while too busy upstream.
I've just restarted yesterday to process my Debian stack (with
powerman and pwrkap).
so it will take me a bit more time to complete the nut part...

cheers,
Arnaud
-- 
Linux / Unix Expert RD - Eaton - http://www.eaton.com/mgeops
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/



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

Bug#531220: nut.conf overwritten during reinstall with not prompting

[Arnaud Quette]

2009/6/28 Manolo Díaz da...@pleione.es

 El Sun, 28 Jun 2009 21:47:28 +0200
 Arnaud Quette aquette@gmail.com escribi�:

  Hi Daniel and Manolo,
 
  nut.conf is listed as a conffile (automagically by dh_installdeb).
  but the issue is probably the MODE reprocessing at postinst which
  fails when it is source'able (ie MODE=... without spaces). this
  result in an empty string (MODE=).
 
  can you confirm that you end up with the same result?
 
  cheers,
  Arnaud

 Hi,

 doing 'dpkg-reconfigure nut' it will change the line 'MODE=standalone'
 to 'MODE=' in the file /etc/nut/nut.conf

 But if I previously change 'MODE=standalone' to 'MODE =standalone' or to
 'MODE = standalone' the space(s) will be removed and nut will start.
 'MODE= standalone' will fail too.

 So yes, I think your guesses are right.


Hi Manolo,

thanks for the confirmation. I'll do the fix and an upload soon (being back
from a month off is a hell!).

cheers
Arnaud
-- 
Linux / Unix Expert RD - Eaton - http://www.eaton.com/mgeops
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/

Bug#531220: nut.conf overwritten during reinstall with not prompting

[Arnaud Quette]

Hi Daniel and Manolo,

nut.conf is listed as a conffile (automagically by dh_installdeb).
but the issue is probably the MODE reprocessing at postinst which fails when
it is source'able (ie MODE=... without spaces). this result in an empty
string (MODE=).

can you confirm that you end up with the same result?

cheers,
Arnaud
-- 
Linux / Unix Expert RD - Eaton - http://www.eaton.com/mgeops
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/

Bug#530869: Workaround tested

[Arnaud Quette]

Hi Martin,

2009/5/28 Martin Maney ma...@two14.net

 I had a chance to test this on the Lenny machine where the problem was
 first seen.  Replacing one line in the init script allows the machine
 to send the shutdown command to the UPS:

   poweroff)
 flag=`sed -ne 's#^ *POWERDOWNFLAG *\(.*\)$#\1#p' /etc/nut/upsmon.conf`
 wait_delay=`sed -ne 's#^ *POWEROFF_WAIT= *\(.*\)$#\1#p'
 /etc/default/nut`
 if [ -f $flag ] ; then
 -  if /sbin/upsmon -K /dev/null 21 ; then
 +  if true ; then
 log_daemon_msg Shutting down the UPS ...

 Apparently the author doesn't entirely trust upsmon -K or something,
 since the preceeding line has already found the kill file; all upsmon
 adds, according to the man page, is a check of the text in it.
 Harmless when it works...


I just saw your report, thanks for it.

to answer the above, upsmon -K will not only check if the POWERDOWNFLAG file
exists, but also if it contains the right magic (just to be sure that only
touching the files won't allow to poweroff the UPS!)

so, your above patch will obviously work, but will also remove a security
harness.
it's acceptable as a temp solution, but I will do my best to prioritize an
upload for Lenny.

cheers,
Arnaud
-- 
Linux / Unix Expert RD - Eaton - http://www.eaton.com/mgeops
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/

Bug#528222: nut.conf.5: Suggested man page for nut.conf

[Arnaud Quette]

tags 528222 + upstream
thanks

Hi,

just to let you know that I've commited your patch upstream.
It will so be available in nut 2.4.2

thanks for your contrib,
Arnaud
-- 
Linux / Unix Expert RD - Eaton - http://www.eaton.com/mgeops
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/

Bug#520445: speech-tools: tries to overwrite file owned by powerman

[Arnaud Quette]

salut Ralf,

2009/4/3 Ralf Treinen trei...@free.fr

 Hello Kumar, Arnaud,

 On Thu, Apr 02, 2009 at 08:53:21AM -0500, Kumar Appaiah wrote:
  On Thu, Apr 02, 2009 at 03:44:05PM +0200, Arnaud Quette wrote:
  2009/4/2 Kumar Appaiah [1]a.ku...@alumni.iitm.ac.in
I have uploaded speech-tools/1:1.2.96~beta-4 to unstable, which is
supposed to fix this problem. Unfortunately, it looks as though it
will not migrate to testing automatically as it says Updating
speech-tools introduces new bugs: #520445 on the PTS page. Does
powerman also require an upload? Or is there a way to indicate
 that
this issue has been sorted out?
  
Thanks, and sorry for the trouble.
  
  have you marked the bug as being closed by your upload (ie adding a
  Closes: #520445 in debian/changelog). Since the bug is shared by
 the 2
  packages, this should fix the situation.
  cheers,
 
  Seems so:
 
  http://packages.qa.debian.org/s/speech-tools/news/20090328T153211Z.html
 
  In fact, the graph generated in the BTS also shows this aspect, which
  led me to the confusion.

 Normally it should be OK when one of the two packages closes the bug.
 That is the sematics of assigning a bug to two packages. However,
 I am not sure whether that feature of the BTS is used a lot so I
 wouldn't exclude completely that there is a bug. Please observe
 what is going on with the packages, if they continue to be blocked
 from testing migration please talk to the release team.

 Anyway, hanks for fixing taht bug :-) -Ralf.


I've an upload scheduled for i10n and at least 2 bug fixes around april 14.
so for my part, if nut is still blocked, that will trigger a rebuild...

cheers,
Arnaud
-- 
Linux / Unix Expert RD - Eaton - http://www.eaton.com/mgeops
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://people.debian.org/~aquette/
Free Software Developer - http://arnaud.quette.free.fr/

Bug#520445: speech-tools: tries to overwrite file owned by powerman

[Arnaud Quette]

Hi Kumar,

2009/4/2 Kumar Appaiah a.ku...@alumni.iitm.ac.in

 Dear Arnaud and Ralf (Jim kept in CC),

 I have uploaded speech-tools/1:1.2.96~beta-4 to unstable, which is
 supposed to fix this problem. Unfortunately, it looks as though it
 will not migrate to testing automatically as it says Updating
 speech-tools introduces new bugs: #520445 on the PTS page. Does
 powerman also require an upload? Or is there a way to indicate that
 this issue has been sorted out?

 Thanks, and sorry for the trouble.


have you marked the bug as being closed by your upload (ie adding a Closes:
#520445 in debian/changelog). Since the bug is shared by the 2 packages,
this should fix the situation.

cheers,
Arnaud
-- 
Linux / Unix Expert RD - Eaton - http://www.eaton.com/mgeops
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://people.debian.org/~aquette/
Free Software Developer - http://arnaud.quette.free.fr/

Bug#518391: Patches for coherence

[Arnaud Quette]

2009/3/19 charliej cj...@cableone.net

 Arnaud,


Hi Charlie,


 I made the changes to the rules file that you suggested.  IMHO worked
 much better.


sure ;-)


 Both manpages have been created.  I had a real problem with the
 manpages.  I would get lintian errors on the .deb but not on the source.
 I tried several name combination which did not work.  During the test
 install I manually verified that the manpages where installed
 to /usr/share/man/man1 which they where, so I included a lintian
 override file.


* quickly looking, this must be due to the naming:
the manpages name have to match the binaries name.
so the fix here is to rename:
- python-coherence.1 to coherence.1
- python-coherence-applet.1 to applet-coherence.1 (beware of the words
ordering).

* while you're working on that, you should also modify the 3rd .TH field of
the manpage to put the last manpage modification date (ie Thu Mar 19
2009). It seems to be the standard here (thought I'm not a groff / man
guru!) and is more useful than sticking with a software release that is
always changing without mandatory impact on the manpage...

* lastly, you have a typo in the changelog:
+ * Added debain/python-coherence.lintian-overrides
 ^^
or are you trying to fork a new Debian based distro ;-p

having the above, we should be fine.
Otherwise, I'll take on me to make the remaining changes and ping you for
the ubuntu sync on the Debian upload is done. alright?

cheers,
Arnaud
-- 
Linux / Unix Expert RD - Eaton - http://www.eaton.com/mgeops
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer -
http://people.debian.org/~aquette/http://people.debian.org/%7Eaquette/
Free Software Developer - http://arnaud.quette.free.fr/

Bug#518391: Patches for coherence

[Arnaud Quette]

2009/3/19 charliej cj...@cableone.net

 On Thu, 2009-03-19 at 13:03 +0100, Arnaud Quette wrote:

 [snip]
 
  * quickly looking, this must be due to the naming:
  the manpages name have to match the binaries name.
  so the fix here is to rename:
  - python-coherence.1 to coherence.1
  - python-coherence-applet.1 to applet-coherence.1 (beware of the words
  ordering).
 
 The above naming scheme is what I tried first.  I have changed the
 manpage names to what you suggest and I still get the no-manpage
 lintian error for coherence and applet-coherence but yet the manpages
 are installed to the correct location.  Should I use the override file?
 hmmm I wonder if this could be a possible bug in lintian?

 I only get this error when running lintian on the .deb.  When I run
 lintian on the source package (dsc, changes) I do not get this error.


have you also updated debian/python-coherence.manpages accordingly?

remember that you have 3 points:
- the manpage file name
- the manpage title (ie .TH NAME)
- the reference in the .manpages file

ensure that the 3 are the same

 * while you're working on that, you should also modify the 3rd .TH
  field of the manpage to put the last manpage modification date (ie
  Thu Mar 19 2009). It seems to be the standard here (thought I'm not
  a groff / man guru!) and is more useful than sticking with a software
  release that is always changing without mandatory impact on the
  manpage...
 
 Done

  * lastly, you have a typo in the changelog:
  + * Added debain/python-coherence.lintian-overrides
   ^^
  or are you trying to fork a new Debian based distro ;-p
 
 hahahahaha, no, no, not forking, just a typo :)
 Done


;-)


 
  having the above, we should be fine.
  Otherwise, I'll take on me to make the remaining changes and ping you
  for the ubuntu sync on the Debian upload is done. alright?

 Cool
 I have pushed the changes to the launchpad branch


ok, I'll check that hopefully this evening if the children are not as ill as
yesterday!

thanks for your work on this Charlie.
we'll possibly have a private discussion on packaging together... in the
meantime, if you have any questions or doubt, feel free to contact me. I
have currently a slot allocated to you ;-)

Arnaud

Bug#520445: speech-tools: tries to overwrite file owned by powerman

[Arnaud Quette]

Salut Ralph, Jim,

@Jim (Powerman upstream):
speech-tools and powerman both install files with the same name (namely pm
and its manpage).
while the latter has already been reported and somehow fixed [1] (thanks
Kumar BTW ;-), the former [2] wasn't. The full bug reports are linked below.

A quick investigation seems to show that the problem is limited to these 2
files.

The best solution is to solve this upstream, by renaming one or the other.
In PowerMan, pm stands well for Power Man, and is the client tool.
What is exactly pm in speech-tools?

@Jim (partly off-topic):
I personaly feel that 2 letters command names should be kept for the base
system itself (ls, cp, rm, ...)
A possible quick and acceptable (?) solution would be to rename Powerman's
pm to pmc or pmclient or powermanc or whatever suits you and is coherent.
Note that NUT currently use the former with upsc, but the reflexion underway
with the new PDU support is to merge the 3 client tools (upsc, upscmd,
upsrw) into a single nutclient or nut-client or ... you get the idea.
that might be another point in favor of the nut merge ;-)

cheers,
Arnaud
--
[1] http://bugs.debian.org/520001
[2] http://bugs.debian.org/520445
-- 
Linux / Unix Expert RD - Eaton - http://www.eaton.com/mgeops
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://people.debian.org/~aquette/
Free Software Developer - http://arnaud.quette.free.fr/

Bug#520445: speech-tools: tries to overwrite file owned by powerman

[Arnaud Quette]

Hi Kumar,

Jim has a point with the compat, and the fact that power related topics are
*very* sensible.
so thanks for opening the door.

2009/3/19 Kumar Appaiah a.ku...@alumni.iitm.ac.in

 Dear Arnaud,

 On Thu, Mar 19, 2009 at 10:39:44PM +0100, Arnaud Quette wrote:
 The best solution is to solve this upstream, by renaming one or the
 other.
 In PowerMan, pm stands well for Power Man, and is the client tool.
 What is exactly pm in speech-tools?

 It is a non-sophisticated pitchmarking Perl script. Because the
 pitchmark program does this anyway, I don't think there should be a
 problem in renaming pm to something more sensible, though I can't
 think of any such name. Do you have a suggestion?


since I don't use these, and have only a vague idea of the purpose, it's a
bit hard.
moreover knowing that there is already a pitchmark binary with a man
placeholder too!
a few possibilities: simple-pitchmark, perl-pitchmark

cheers,
Arnaud
-- 
Linux / Unix Expert RD - Eaton - http://www.eaton.com/mgeops
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://people.debian.org/~aquette/
Free Software Developer - http://arnaud.quette.free.fr/

Bug#511955: Fails to build since libupsclient moved to /lib

[Arnaud Quette]

2009/1/15 James Westby jw+deb...@jameswestby.netjw%2bdeb...@jameswestby.net


 Package: wmnut
 Version: 0.62-3
 Severity: important
 Tags: patch
 User: ubuntu-de...@lists.ubuntu.com
 Usertags: origin-ubuntu jaunty ubuntu-patch

 Salut Arnaud,


hello James,

I'm so sorry. I've completly forgotten that one :(
if you see me MIA, ping me directly... I'm on far too many things, and it
happens that I miss or forget something. I'm also a human after all ;-)

Your package failed to build on Ubuntu, since libupsclient moved to
 /lib.


uh, right.

Rather than trying to tackle the configure macros that it used I
 switched it to pkg-config.

The attached patch is a little large though, sorry, as I had to run
 aclocal and autoconf for that change. Then when you build that it
 sometimes fails as it tries to re-run automake and autoheader. So
 I added AM_MAINTAINER_MODE and called ./configure with
 --disable-maintainer-mode to avoid that. This involved re-running
 automake though, so the diff is even larger.


wmnut still aims to be the bare X11 NUT app, and many systems still don't
ship pkg-config, at least not by default. so upstreamly speaking, I'll
rewritte the configure.ac but using both the pkg-config + nut-config to
address all use cases.

but to meat everybody's timeframe, I'll first make a 0.62-4 with a minimal
patch based on yours.
I'll then log an LP bug for requesting the Debian sync.

thanks and apologies again, I owe you a beer (maybe in Barça ;-)

cheers,
Arnaud
-- 
Linux / Unix Expert RD - Eaton - http://www.eaton.com/mgeops
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer -
http://people.debian.org/~aquette/http://people.debian.org/%7Eaquette/
Free Software Developer - http://arnaud.quette.free.fr/

Bug#511955: Fails to build since libupsclient moved to /lib

[Arnaud Quette]

James,

a complementary note: nut 2.4 (the version in Jaunty) has removed the
compat. with UPSCONN (the client structure) to the profit of UPSCONN_t only.

thus you'll end up with an FTBTS.
this is also fixed in 0.62-4 (not far from upload).
also note that 0.63 is underway, but it's not worth an FFE imo.

cheers,
Arnaud

Bug#518391: Patches for coherence

[Arnaud Quette]

Hey Charlie,

2009/3/17 charliej cj...@cableone.net

 On Mon, 2009-03-16 at 15:50 +0100, Arnaud Quette wrote:
 
  2009/3/14 charliej
  Arnaud,
 
  Hey Charlie,
 
 
 
  Thank you for looking at this, IMHO this update will benefit
  Ampache and
  Rythmbox users.  If there is any other way I can help out feel
  free to
  contact me.
 
  sure, become a Debian Maintainer (or a DD) and adopt coherence,
  please ;-)

 Working on it!  Actually I am thinking of going through the NM process.


eh, nice ^_^


 Having a problem of finding a Debian Member that lives close to me to
 get my key signed, but anyway that's a different can of worms.


well, it's an important point since it officially confirms your digital
identity for Debian!
you really have to put a high prio on this point and attend to an event or
manage somehow to get a DD signing your key.

I would be willing to take over python-coherence, as long as I could
 call on you from time to time with questions/sponsorship of package
 updates.


sure, I'm very opened to training the new generation. it's part of a DD
role ;-)


  I am the current maintainer of Ampache and Ampache-themes.
 
 
  more seriously, have you tested your patch?

 yes, but I now understand why the install and test worked but the actual
 patch did not work.


;-) you should never let false fixed go out. prefer to call to somebody or
RFH if needed.
using pdebuild is helpful to get the latest lintian.
also see my below cdbs remark.

 I've noticed several things there:
  - DEB_INSTALL_ARGS += -XMochiKit should be DEB_DH_INSTALL_ARGS +=
  -XMochiKit

 I am still unraveling the mysteries of CDBS and python packages.  But
 after working on this package it makes more sense, but still have a lot
 to learn.


an hint with cdbs is to directly look at .mk files. these are fairly well
commented, and I found this more useful than the doc. the online examples
can be helpful too.
for debhelpers (ie dh_install), it's /usr/share/cdbs/1/rules/debhelper.mk

be sure that we always have to learn. life wouldn't be fun otherwise ;-)

 but will not be helpfull since the setup.py install the files directly
  to python-coherence.
  for the above to work, we should first go through debian/tmp using
  DEB_DESTDIR


I've missed to mention the quick solution:
binary-predeb/python-coherence::
/bin/rm -f
debian/python-coherence/usr/share/pyshared/coherence/web/static/MochiKit.js

note that both solutions are fine here since the fix is limited to 1 file.
so the move to tmp not really needed.
if in the future there is a need to split and spawn new binary pkg, then you
should go that way and use the .install files...

 - the added Build-dep doesn't add the coma to the previous entry,
  - there was a typo in the added manpage (AVAILAB*L*E STORES)

 I have pushed these changes to the launchpad branch.


I've also noticed a strange .TH format (soft release instead of last edit
date), but have not read it thoroughly .

 - there is still a manpage missing for applet-coherence

 my bad missed that one hmmm.  Going to get started on this in the am,
 along with rebuilding/testing the package with the above changes.  I
 will post back when the manpage and tests are complete.


great, thanks.
note that as soon as your diff is validated, I'll upload the new release
with an added Uploaders field for you ;-)
that will be the first step of the take over.

 I'm still working on this, but in very low prio background mode... but
  would be interested in some feedback from you since I don't use
  coherence nor the associated software...

 That's fine, an associate program Ampache-3.5 is due out in about a
 month or so.  Python-coherence makes use of Ampache's XML-API, and there
 will be some significant changes to the API with the 3.5 release, so
 this update of python-coherence is needed so coherence and ampache play
 nice. :)  My intent, is to have both updated packages hit the archives
 at around the same time, if possible.


leave a bit of time for the build-dep (ie coherence) to get buildd job's
done, before sending ampache.
delaying by a day, and watching buildd logs to ensure everything is fine for
coherence is a good idea.
this will save build resources from failing to build to due the missing
coherence dep ;-)

cheers,
Arnaud

Bug#518391: Patches for coherence

[Arnaud Quette]

2009/3/14 charliej

 Arnaud,


Hey Charlie,



 Thank you for looking at this, IMHO this update will benefit Ampache and
 Rythmbox users.  If there is any other way I can help out feel free to
 contact me.


sure, become a Debian Maintainer (or a DD) and adopt coherence, please ;-)

more seriously, have you tested your patch?
I've noticed several things there:
- DEB_INSTALL_ARGS += -XMochiKit should be DEB_DH_INSTALL_ARGS +=
-XMochiKit
but will not be helpfull since the setup.py install the files directly to
python-coherence.
for the above to work, we should first go through debian/tmp using
DEB_DESTDIR
- the added Build-dep doesn't add the coma to the previous entry,
- there was a typo in the added manpage (AVAILAB*L*E STORES)
- there is still a manpage missing for applet-coherence

I'm still working on this, but in very low prio background mode... but would
be interested in some feedback from you since I don't use coherence nor the
associated software...

cheers,
Arnaud
-- 
Linux / Unix Expert RD - Eaton - http://www.eaton.com/mgeops
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer -
http://people.debian.org/~aquette/http://people.debian.org/%7Eaquette/
Free Software Developer - http://arnaud.quette.free.fr/

Bug#518391: Patches available for Update Coherence

[Arnaud Quette]

Hi Charlie,

2009/3/13 charliej cj...@cableone.net

 Ahh, jeeze just noticed the above Subject line (I would have ignored
 it), changing it to something that will catch someones attentions.


I still have an answer to your prev mail blocked in my draft box.
I've started to look at coherence update... so work underway

sorry for not having replied earlier, and thanks for your contrib.

cheers,
Arnaud
-- 
Linux / Unix Expert RD - Eaton - http://www.eaton.com/mgeops
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://people.debian.org/~aquette/
Free Software Developer - http://arnaud.quette.free.fr/

Bug#514733: ITP: pwrkap -- Centralized Power Distribution Unit (PDU) management

[Arnaud Quette]

Package: wnpp
Severity: wishlist

* Package name: pwrkap
Version: 7.20
Author: Darrick J. Wong djw...@us.ibm.com
(C) Copyright IBM Corp. 2008
* URL : http://pwrkap.sourceforge.net
* License: GPL 2
Description : Energy use monitor and Power Cap enforcement tools
pwrkap is a set of utilities that monitor computer energy consumption
and enforces an upper limit on the amount of power consumed by the
computer at any given time.


Side notes:
- I'm in touch with the upstream author (Darrick J. Wong from IBM),
- a new release is scheduled with fixes following my recent audit,
- 2 packages will be provided, to lower Depends and allow headless
installation: pwrkap and pwrkap-gui

cheers,
Arnaud
-- 
Linux / Unix Expert RD - Eaton - http://www.eaton.com/mgeops
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://people.debian.org/~aquette/
Free Software Developer - http://arnaud.quette.free.fr/

Bug#499486: debhelper: dh_installinit should be able to use upstream's init file

[Arnaud Quette]

seconded!

powerman provides a sane LSB init script too, and I would prefer to use it
without a gross hack.
ITP underway: http://bugs.debian.org/506903

thanks to consider this feature,
Arnaud
-- 
Linux / Unix Expert RD - Eaton - http://www.eaton.com/mgeops
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://people.debian.org/~aquette/
Free Software Developer - http://arnaud.quette.free.fr/

Bug#505101: Reopening #505101: fix in 2.2.2-9 broken; libupsclient.la also points to /usr/lib

[Arnaud Quette]

Hi Sebastian,

thanks for poping this up.

Morten Kjeldgaard, from Ubuntu, already pointed it and provided an
excellent package update, using debhelper files:
https://bugs.edge.launchpad.net/ubuntu/+source/nut/+bug/299489

as told, I'll do my best to integrate these update and upload 2.2.2-10.
though my top 1 priority is currently to have 2.4.0 released for Christmas...

thanks for your support and help,
Arnaud
-- 
Linux / Unix Expert RD - MGE Office Protection Systems - http://www.mgeops.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://people.debian.org/~aquette/
Free Software Developer - http://arnaud.quette.free.fr/



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#506903: ITP: powerman -- Centralized Power Distribution Unit (PDU) management

[Arnaud Quette]

Package: wnpp
Severity: wishlist

* Package name: powerman
Version: 2.3
Author: The Regents of the University of California.
Produced at Lawrence Livermore National Laboratory
Written by Andrew Uselton [EMAIL PROTECTED]
   Jim Garlick [EMAIL PROTECTED]
   Al Chu [EMAIL PROTECTED]
   Chris Dunlap [EMAIL PROTECTED]
* URL : http://powerman.sourceforge.net
* License: GPL 2+
Description : Centralized Power Distribution Unit (PDU) management

 PowerMan is a tool for manipulating Power Distribution Units (PDUs) from a
 central location. It is suitable for remote operation in data centers or
 compute cluster environment.
 .
 Several RPC varieties are supported natively by PowerMan and
 Expect-like configurability simplifies the addition of new devices.
 .
 This package includes support for Genders, HTTP devices and Curses user
 interface.


Side notes:
- I'm in touch with the upstream maintainer (Jim Garlick),
- a new release is scheduled with some fixes planned, following my recent audit,
- a client library (libpowerman) will soon be available, to allow the
remote manipulation of a Powerman daemon,
- an integration of this library is underway in the Network UPS Tools.

cheers,
Arnaud
-- 
Linux / Unix Expert RD - MGE Office Protection Systems - http://www.mgeops.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://people.debian.org/~aquette/
Free Software Developer - http://arnaud.quette.free.fr/



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]