[Nut-upsdev] Re: Nut-upsdev Digest, Vol 22, Issue 5

khurram shaker khurram shaker khurram_shaker at yahoo.com
Sun Apr 8 15:55:32 UTC 2007

1 - its on load blinking battery LEDs  and not giving proper back up time . APC sua1000i

nut-upsdev-request at lists.alioth.debian.org wrote:  Send Nut-upsdev mailing list submissions to
nut-upsdev at lists.alioth.debian.org

To subscribe or unsubscribe via the World Wide Web, visit
or, via email, send a message with subject or body 'help' to
nut-upsdev-request at lists.alioth.debian.org

You can reach the person managing the list at
nut-upsdev-owner at lists.alioth.debian.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Nut-upsdev digest..."

Today's Topics:

1. Re: questions re. patching bcmxcp.c and choosing
variable names (Oliver Wilcock)
2. Buildbot up and running (Charles Lepple)


Message: 1
Date: Sat, 7 Apr 2007 15:20:16 -0400 (EDT)
From: "Oliver Wilcock" 
Subject: Re: [Nut-upsdev] questions re. patching bcmxcp.c and choosing
variable names
To: nut-upsdev at lists.alioth.debian.org
Message-ID: <63999. at shonsu.owch.ca>
Content-Type: text/plain;charset=iso-8859-1

Note quite the same as load.off. I think load.off is intended to turn off
the load permanently. load.n.cycle sounds more appropriate.

> Hi Oliver!
>> I've patched bcmxcp.c such that it can power cycle the outlet load
>> segments independently on a Powerware PW5125 UPS. I presume that it
>> will
>> work for any XCP protocol UPS with 2 load segments.
> Just to make sure I understand what this does, would this do the same as
> sending
> load.off
> load.on
> for just one output?


Message: 2
Date: Sat, 7 Apr 2007 20:51:51 -0400
From: "Charles Lepple" 
Subject: [Nut-upsdev] Buildbot up and running
To: "NUT developers" 

Content-Type: text/plain; charset=ISO-8859-1; format=flowed

I guess I have absorbed a bit of the agile development philosophy, or
maybe I am a sucker for automatically generated status displays, but
whatever the reason, we now have a Buildbot running:


The idea is that anytime someone checks a new SVN revision into NUT,
the buildbot master will ask the slaves to check out the changes and
build NUT.

Since the build process consists of a 'make distcheck', we end up with
a SVN snapshot with ./configure already built. This should help new
users who might not have all the autotools installed.

At the moment, the buildbot slaves are the ragtag collection of
computers I have lying around the house. I am still working on a umask
problem with the generated tarballs, but eventually, you will be able
to click on the tarball link and grab whatever just got built. The
only one that you should expect to be on continuously is the G4 Cube
in the first column.

Any volunteers to add to the "botnet"? All you need is Python and
Twisted (I think); everything else gets pushed over the network. The
machine doesn't have to be directly accessible from the Internet - the
slave buildbot process connects back to the master whenever the slave
machine is up. This would be a great way to make sure that things
checked in to the trunk don't break Solaris, for instance. Contact me
off-list for details on setting up a slave.

The main Buildbot web site:


- Charles Lepple


Nut-upsdev mailing list
Nut-upsdev at lists.alioth.debian.org

End of Nut-upsdev Digest, Vol 22, Issue 5

We won't tell. Get more on shows you hate to love
(and love to hate): Yahoo! TV's Guilty Pleasures list.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20070408/36f43804/attachment.htm

More information about the Nut-upsdev mailing list