similar to: [nut-commits] svn commit r1207 - in trunk: . include

Hello all, I'm trying to compile the 2.6.5 tarball on a non-developer system (a freshly installed OpenIndiana zone). Right away the make failed due to revision checks (fixed below) due to missing git and svn software (and for make, a failed step fails everything). The fix is to catch the non-zero return codes and just successfully set an empty string. Barring this, the default

I just noticed this warning from the autoreconf portion of the buildbot log: autoreconf: running: automake --no-force include/Makefile.am:9: shell unset LANG && svnversion -n $(top_srcdir: non-POSIX variable name include/Makefile.am:9: (probably a GNU make extension) include/Makefile.am:10: shell if test "$(SVNREV: non-POSIX variable name include/Makefile.am:10: (probably a GNU make

This is the patch to include SVN revision level in version number displays. There should be two enclosures; the patch itself and a new source file. common/upsversion.c. upversion.c defines a single function. upsversion(), that returns a version string for display. Some Makefile trickery ensures that this file will be recompiled whenever the project's SVN revision level has changed since it

Hi Arjen, there is a small glitch with r1376: upsd.c: In function ?mainloop": upsd.c:857: warning: too few argument for the format 2008/3/18, Arjen de Korte <adkorte-guest at alioth.debian.org>: > Author: adkorte-guest > Date: Tue Mar 18 19:59:15 2008 > New Revision: 1376 > ... > + if (ret == 0) { > + upsdebugx(2, "%s: no data

Regid, You suggested we remove nut_version.h from the .orig.tar.gz for NUT: <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=613643> The original intent was that nut_version.h would be generated from "make dist" (or "make distcheck*") when the official nut-X.Y.Z.tar.gz tarball is created. At that point, it is safe to assume that there is no longer any local version

Julius: I just realized after committing Michal's patch that you have a more comprehensive patch on the tracker that approaches this piece of code differently. We can go ahead and apply the following patch to the trunk if you still think it's relevant: https://alioth.debian.org/tracker/index.php?func=detail&aid=303719&group_id=30602&atid=411544 If you have a newer version of

On Feb 1, 2008 6:11 PM, Arnaud Quette <aquette at alioth.debian.org> wrote: > Author: aquette > Date: Fri Feb 1 23:11:33 2008 > New Revision: 1264 > > Log: > fix HAL support installation [Alioth Bug #304156] Arnaud, I tried to fix some of the errors that I was seeing in buildbot, but I still get the following error on "make distcheck", and I don't know how

a really good idea Charles ;-) 2007/7/11, Charles Lepple <clepple-guest at alioth.debian.org>: > Author: clepple-guest > Date: Wed Jul 11 03:20:44 2007 > New Revision: 1025 > > Log: > Added bash completion script for 'upsc'. > ... you should also consider adding a Makefile + configure test for auto installation (based upon the existence of

Arnaud, I hope you don't mind that I took the liberty to sync the Makefile.am with what is actually checked in. It looks like there may have been some other translations at some point, but then again, there are some translations for text that is not in nut.templates. Things probably need to be synced up a little more, and I just wanted to turn the buildbot box green again. On Sun, May 11,

On Feb 18, 2012, at 10:19 PM, Charles Lepple wrote: > Author: clepple-guest > Date: Sun Feb 19 03:19:02 2012 > New Revision: 3448 > URL: http://trac.networkupstools.org/projects/nut/changeset/3448 > > Log: > Don't allocate storage for variables in bcmxcp.h > > The header files should declare variables as extern, and they should be > allocated in only one .c

Hey Charles, adding Arjen to the list and upsdev for info... 2008/12/17 Charles Lepple <clepple at gmail.com>: > I noticed Arjen deleted the packaging/debian directory as well. > > I suppose the same argument applies to packaging/debian/ as to the *.spec > files: it should track the specific distribution as well as NUT changes. > > However, it might make sense to keep

Charles Lepple wrote: > > Author: clepple-guest > Date: Mon Dec 4 03:00:57 2006 > New Revision: 609 > > Modified: > trunk/ChangeLog > trunk/configure.in > Log: > Undoing changeset [608]. It fails with this error: > > configure: error: conditional "HAVE_LIBUSB" was never defined. > Usually this means the macro was only invoked

Arjen, let me know if this commit agrees with the intent of the recent Mandriva changes. It was breaking the automated builds. I'll apply it to Testing if there are no objections. - Charles On May 5, 2008, at 10:38 PM, Charles Lepple wrote: > Author: clepple-guest > Date: Tue May 6 02:38:05 2008 > New Revision: 1475 > > Log: > configure.in: tell autoconf to generate

Charles Lepple wrote: > Author: clepple-guest > Date: Fri Aug 15 23:49:44 2008 > New Revision: 1520 > > Log: > drivers/tripplite_usb.c: Increase send retries to 10 (as needed by some > protocol 2001 units) Would you mind if I made an attempt to re-engineer the reconnection and USB error handling code of this driver? Best regards, Arjen

On May 16, 2012, at 10:10 AM, Arnaud Quette wrote: > Author: aquette > Date: Wed May 16 14:10:40 2012 > New Revision: 3603 > URL: http://trac.networkupstools.org/projects/nut/changeset/3603 > > Log: > Final fix to the tcsetattr() / tcgetattr() issue I propose reverting this commit for now, until we work in all of the autoconf magic to detect whether the various termio bits

On Oct 4, 2012, at 6:50 PM, Arnaud Quette wrote: > +/* IPMI auth defines, simply using FreeIPMI defines */ > +#ifndef IPMI_AUTHENTICATION_TYPE_NONE > + #define IPMI_AUTHENTICATION_TYPE_NONE 0x00 > + #define IPMI_AUTHENTICATION_TYPE_MD2 0x01 > + #define IPMI_AUTHENTICATION_TYPE_MD5 0x02 > + #define

On Wed, 2011-09-14 at 12:25 +0000, Charles Lepple wrote: > Author: clepple-guest > Date: Wed Sep 14 12:25:03 2011 > New Revision: 3226 > URL: http://trac.networkupstools.org/projects/nut/changeset/3226 > > Log: > Include <string.h> for nut-scanner > > Modified: > trunk/tools/nut-scanner/scan_snmp.c > trunk/tools/nut-scanner/scan_usb.c > >

oops, this wasn't supposed to make it into the trunk yet. I can revert it until further testing, but has anyone else tried running with this patch? http://lists.alioth.debian.org/pipermail/nut-upsdev/2009-April/003821.html On Mon, May 4, 2009 at 10:05 PM, Charles Lepple <clepple-guest at alioth.debian.org> wrote: > Author: clepple-guest > Date: Tue May 5 02:05:09 2009 > New

On Wed, 2011-09-14 at 12:24 +0000, Charles Lepple wrote: > Author: clepple-guest > Date: Wed Sep 14 12:24:58 2011 > New Revision: 3225 > URL: http://trac.networkupstools.org/projects/nut/changeset/3225 > > Log: > Silence redefined PACKAGE_ macro warnings > > This should be fixed properly upstream, but in the mean time, the SNMP-based > tools can't use these

On Wed, Dec 3, 2008 at 4:05 PM, Arjen de Korte <nut+devel at de-korte.org> wrote: > Citeren Charles Lepple <clepple at gmail.com>: > >> Note that this is the same VID/PID as on this example on the Lakeview >> Research home page: >> >> http://www.lvr.com/usb_on_a_budget.htm >> >> We can include the name "Lakeview Research" in the