similar to: Character maps

I guess this means we won't have access to SVN, right? Is there a timeline available when this will be fixed? Sadly enough, my keys were generated on an openSUSE system and are probably not affected by this vulnerability anyway. Best regards, Arjen -- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57 -------------- next part -------------- An

THANKS, but the 'megatec' driver only works whith windows OS via USB, and i need it for red hat OS with USB-serial connection... Please, anybody can help me.... nut-upsuser-request@lists.alioth.debian.org escribi?: Send Nut-upsuser mailing list submissions to nut-upsuser@lists.alioth.debian.org To subscribe or unsubscribe via the World Wide Web, visit

-- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57 > Is there any reason we don't just do serial PnP? Do UPSes not generally support this? Unfortunately, many cheap ones don't or have implementation flaws (the Sweex 1000 for instance, which calculates the CRC in the wrong way). In fact, there are a fair number of UPSes in the list of

> Author: adkorte-guest > Date: Mon Jun 25 19:26:09 2007 > New Revision: 988 > > Log: > Update to reflect changes in the way we deal with dstate_dataok() and > dstate_datastale(). > > Historically it was needed to call dstate_dataok() regularly, to prevent > staleness warnings. This is no longer needed, now the server will PING > drivers it has not heard of

> ---------- Forwarded message ---------- > From: Arjen de Korte > To: nut-commits at lists.alioth.debian.org > Date: Mon, 27 Aug 2007 18:33:00 +0000 > Subject: svn commit r1076 - in trunk: . drivers > Author: adkorte-guest > Date: Mon Aug 27 18:33:00 2007 > New Revision: 1076 > > Log: > * drivers/libhid.[ch],libshut.[ch],libusb.[ch]: > - Cut the libshut and

It is possible at least on linux to get the port associated with a device from userspace - I'd assume that on each platform it's possible, just that libusb is incomplete (on top of being undocumented). Here's a patch for matching portnum on linux, with a few pieces pulled from libusb. It lacks autoconf macros to isolate it -- but it does appear to work. Regards, Alex Peyser On

> +22 = Gamatronic UPSs with alarm interface > + [CP=RTS] [OL=CTS] [LB=\-DCD] [SD=DTR] > + > +22 = CyberPower SL seriess > + [CP=RTS] [OL=CTS] [LB=\-CAR] [SD=DTR] > + > + This part of the patch is no good. While TIOCM_CAR is equivalent to TIOCM_CD (at least in some implementations) CAR certainly isn't handled the same as DCD by genericups. It won't be

Browsing through the newhidups.c code, I stumbled across the following: /* master list of avaiable subdrivers */ static subdriver_t *subdriver_list[] = { #ifndef SHUT_MODE &generic_subdriver, #endif &mge_subdriver, #ifndef SHUT_MODE &apc_subdriver, &belkin_subdriver, &tripplite_subdriver, NULL #endif }; Shouldn't the 'NULL' terminator be outside the

Looking for ioctl() calls in the drivers, I noticed that the energizerups.c code looks a lot like a megatec protocol over a USB connection. It uses 8 bytes per packet, which makes it look like the agiler subdriver in megatec_usb. Do we know if there are people that use this driver now and that might be able to verify this? Best regards, Arjen -- Eindhoven - The Netherlands Key fingerprint - 66

Citeren Arnaud Quette <aquette at alioth.debian.org>: > Author: aquette > Date: Mon May 18 12:14:54 2009 > New Revision: 1846 > > Log: > Enable timestamp on output messages (format "%H:%M:%S: msg") I think this should only be done for messages that are sent to stderr. In most cases, syslog will already prepend a timestamp, so this is probably redundant.

> - drivers/dstate-hal.[ch]: added sleep here, to limit the polling rate > (previously, the driver would completely ignore the poll interval and > would run upsdrv_updateinfo() without any delay in between) > > The changes to dstate-hal.[ch] should probably be backported to Testing > ASAP, since ignoring the poll_interval is not a good idea (you'll be > basically polling

Since reports received over the interrupt pipeline are a recurring problem for various types of UPS'es, I propose to simply ignore the data we receive there and only flush the respective report buffer. By doing so, at the time the interrupt reports are processed the first variable that is retreived will trigger a poll for the corresponding feature report and we should be fine. The impact on

> Added: > trunk/scripts/hotplug/Makefile.am > trunk/scripts/udev/Makefile.am > Modified: > trunk/ChangeLog > trunk/Makefile.am > trunk/configure.in > trunk/docs/configure.txt > trunk/scripts/Makefile.am > trunk/scripts/hotplug/ (props changed) > trunk/scripts/udev/ (props changed) > trunk/scripts/udev/README > Log: > -

I don't understand how the info_len element from the hid_info_t structure is used in usbhid-ups. It appears to me that the only use of this element is now to indicate the length of the string: > float info_len; /* if ST_FLAG_STRING: length of the string */ The above is clear, if the element is flagged as a string, the size of this string is put in this variable, so that we can use this in

Hi Peter, The explanation on why I want to flush the report buffer after running instcmd() or setvar() was incorrect. It is not the variable thats get written, that needs to be read fresh from the UPS. That is already handled by HIDSetItemValue(), which reads back the value and thereby refreshes the report buffer. I goofed up here, I looked at the wrong parameters. :-( However, when I change the

Currently, the 'upsd' server uses 'ups.conf' to find out which drivers should be running and uses this information to construct the socketname it needs. This means that drivers that have not been configured in 'ups.conf' can never be seen by the server. If we ever want to autodetect (by whatever means) what drivers are started (udev?) and we start them automatically, this

I'm looking for people that are using the 'cyberpower' driver that has been available for some years now. It seems the overhauled 'powerpanel' driver could support your UPS too. The commands and status bytes used are identical, the only difference being the way the values read for battery charge, temperature and frequency are interpreted. If we can find a way to detect when to

I'm looking for people that are using the 'cyberpower' driver that has been available for some years now. It seems the overhauled 'powerpanel' driver could support your UPS too. The commands and status bytes used are identical, the only difference being the way the values read for battery charge, temperature and frequency are interpreted. If we can find a way to detect when to

Peter, Looking through the usbhid-ups subdrivers, I came across the following function in apc-hid.c, presumably added by you about two years ago (if not, my apologies): 41 /* returns statically allocated string - must not use it again before 42 done with result! */ 43 static char *watts_to_av_conversion_fun(long value) { 44 static char buf[20]; 45 46 snprintf(buf,

> Author: agordeev-guest > Date: Wed Oct 3 00:09:21 2007 > New Revision: 1136 > > Log: > - drivers/megatec_usb.c: added ability to do subdriver-specific > initialization, and moved some shared code to agiler init function > since krauler doesn't need it. [...] I'm not very thrilled about this patch: 1) Down at the subdriver level, one shouldn't use