similar to: Driver removal notification: al175

Hi all! The following files emits warnings when compiled with gcc 4.0: al175.c bcmxcp_ser.c belkinunv.c cyberpower.c everups.c powercom.c solis.c All warnings seem to be of this variety: everups.c:38: warning: pointer targets in passing argument 2 of 'ser_get_char' differ in signedness I suggest that those who fiddles with those drivers fixes the warnings and verifies that it works

On Tue, Jan 27, 2009 at 04:39:13PM +0100, Arnaud Quette wrote: > Hi Kirill, > > 2009/1/27 Kirill Smelkov <kirr at mns.spb.ru> > > > On Tue, Jan 13, 2009 at 05:58:23PM +0300, Kirill Smelkov wrote: > > > Arjen, Arnaud, > > > first of all, I'm sorry for my late reply. > > > > > > If it's not too late, here is updated al175: >

I'm trying to build NUT 2.2.1 on a SunBlade 2000 running Solaris 10 (Solaris 10 11/06 s10s_u3wos_10 SPARC) It won't compile. I'm not a programmer, so I'm afraid I don't know why... [huge at anubis ~/Prog/nut/nut-2.2.1]: ./configure --with-user=ups --with-group=nutNetwork UPS Tools version 2.2.1 checking build system type... sparc-sun-solaris2.10 checking host system type...

make fails at drivers: make[1]: Entering directory `/export/home/zoly/Documents/trunk/drivers' /bin/sh ../libtool --tag=CC --mode=link gcc -I../include -DDBUS_API_SUBJECT_TO_CHANGE -I/usr/include/hal -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/sfw/include -g -Dsolaris2 -I. -I/usr/sfw/include -O -Wall -Wsign-compare -o al175 al175.o ../common/libcommon.a ../common/upsconf.o

Peter, Thanks a lot for your latest changes to newhidups, which I like a lot. Unfortunately, when I tried to build the latest development tree stuff, I got a compile time error when compiling al175.c. It looks to me like my compiler, gcc-3.4.4-2.fc3, doesn't like the macro definition for "RECV(reg) do" because of a poorly inserted comment. I fixed the problem locally by the

Hello up there! Attached is my patch to add support for AL175 alarm module, Please ACK or NAK this. -- ?????? ??????? -------------- next part -------------- A non-text attachment was scrubbed... Name: al175.patch Type: text/x-diff Size: 35632 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20050919/84b639e0/al175-0001.bin

Hi! Is there a way to view ext3 filesystem's maintained journal (in a human-readable-format)? I ask, because i have had a server crash before and now i'm wondering if i might take a look at last things that my server did straight before crash. I guess clarifying log insertions might be lost before buffers were flushed to disk. Thx.

On Nov 18, 2013, at 11:53 AM, Kirill Smelkov wrote: > Please find main description in github issue tracker > > https://github.com/networkupstools/nut/issues/69 > > and, for completness, both patches attached to this mail. This is now part of the 2.7.1 release. Regards, -- Charles Lepple clepple at gmail

Citeren Arnaud Quette <aquette.dev at gmail.com>: > Author: aquette > Date: Sat Nov 15 21:50:40 2008 > New Revision: 1556 > > Log: > USB "improved maintenance" code. Refer to docs/new-drivers.txt for > more information... > > Added: > trunk/drivers/usb-common.c > trunk/drivers/usb-common.h > trunk/tools/ > trunk/tools/Makefile.am >

Hi, Need to get an answer to the following. I find the naming to be little redundant regarding the 'input.transfer.boost.low - hige'. The same goes for input.transfer.trim.low - high. As I find it, there is only one point where the boost or buck (trim) kicks in. Let's say that the nominal voltage is 230 volt, then we have a input.transfer.boost point on say 220 volt. If the

It seems the `libmodbus` library or headers were not found, or something similar - so the driver against it was not built. Did you install `libmodbus-dev` before the build? What does `config.log` in the build root say (and.or the summary shown after you run the `configure` script)? On Sat, Sep 16, 2023 at 7:46?PM FatGear <fatgear1 at free.fr> wrote: > Hi, > > I don't know what

Hello there, I don't think that's working,? I have done all your repo but i don't know how it's supposed to work. I have a idea, change vendor id and product id? to make the driver try to connect to the ups, what do you think of that ? With this driver maybe : usbhid-ups FatGear Le 16/09/2023 ? 20:40, Jim Klimov a ?crit?: > It seems the `libmodbus` library or headers were

On 18/5/25 22:07, Greg Troxel wrote: > Eyal Lebedinsky <eyal at eyal.emu.id.au> writes: > >> I am upgrading to f42. >> >> I get this failure doing "dnf system-upgrade download --releasever=42" >> >> 2025-05-17T21:13:37+1000 CRITICAL Error: Transaction test error: >> file /usr/bin/rhino conflicts between attempted installs of

Thanks for the insights, especially these: > If this is about having variables with thresholds that control devices or cause synthetic setting of some variable (like turning on LB if charge% is < battery.charge.low), then it makes sense. > "battery voltage is unreasonably high" is a reasonable concept. <...> I would not call it HB, though because that makes it sound

hi llvmdev list im currently investigating a missing optimizer feature in VS2010 - and comparing the VS2010 results with the result of clang 3.1 i've downloaded clang from http://llvm.org/releases/download.html -> Experimental Clang Binaries for Mingw32/x86 clang --version clang version 3.1 (branches/release_31) Target: i686-pc-mingw32 Thread model: posix ----- test.c typedef

Jim Klimov <jimklimov+nut at gmail.com> writes: >> "battery voltage is unreasonably high" is a reasonable concept. <...> I >> would not call it HB, though because that makes it sound parallel to LB, >> which is about believed remaining capacity, not detection of overcharging >> failure. > > Well, given that a "battery.charge.high" is

Is anyone besides me using gcc 4.*.*? I noticed that NUT generates an enormous amount of warning noise with that compiler, mostly due to implicit casts between signed/unsigned pointer types. Any volunteers to de-noise the code a bit? The easy way is to insert typecasts; the better way is to actually take care about signedness. -- Peter gcc -I../include -O -Wall -Wsign-compare -c -o everups.o

Jim Klimov via Nut-upsdev <nut-upsdev at alioth-lists.debian.net> writes: > During discussion at > https://github.com/networkupstools/nut/pull/2430#discussion_r1592317940 I > found that while `nut-names.txt` documents the `battery.charge.low` as the > "Remaining battery level when UPS switches to LB (percent)", there is no > counterpart as `battery.charge.high`.

Citeren Kirill Smelkov <kirr at mns.spb.ru>: > So what would we do about this patch? It fails to address the concerns raised, so we have no other option than to reject it. > I've tried to address the issues you've raised, and to describe my > rationale behind alarm(). The use of alarm() here is inappropriate (and possibly incorrect as well, see below). As stated

Well, now that the `subdriver` option got added to `usbhid-ups` too, you can at least try that (by building again the current master). See command-line help for the subdrivers it would currently recognize, and copy e.g. the first word as the matching option, e.g.: ./drivers/usbhid-ups -DDDDDD -d1 -s test -x port=auto -x vendorid=... -x productid=... -x subdriver=... and try to lockpick your