similar to: compiling on Cygwin64

Thank you for responding to my problem I have no problem building in Debian 8 , the problem is with Cygwin64 I see that the two lines from Cygwin64 >> gcc -g -O2 -Wall -Wsign-compare usbhid-ups.c -o usbhid-ups In file included from usbhid-ups.c:32:0: And Debian>>> make[1]: Entering directory '/home/walter/nut/drivers' depbase=`echo usbhid-ups.o | sed

Success !! at least in the compile and build of the Cygwin *.exe's git clone git://github.com/networkupstools/nut.git ./autogen.sh cd nut ./autogen.sh ./configure --with-all=auto --with-doc=auto make install problem was in : /* genericups.c - support for generic contact-closure UPS models Copyright (C) 1999 Russell Kroll <rkroll at exploits.org> This program is free

libusb do you have installed >>> 1.2.6.0-2 ./configure --with-drivers=usbhid-ups Configuration summary: ====================== build serial drivers: yes build USB drivers: yes build SNMP drivers: no build neon based XML driver: yes enable Avahi support: no build Powerman PDU client driver: no build IPMI driver: no build Mac OS X meta-driver: no build i2c based drivers: no enable SSL

I am trying to compile the latest nut version on Cygwin64 and have run into his issue Any Ideas?? gcc -DHAVE_CONFIG_H -I. -I../include -I../include -I/usr/include/neon -g -O2 -Wall -Wsign-compare -MT genericups.o -MD -MP -MF $depbase.Tpo -c -o genericups.o genericups.c &&\ mv -f $depbase.Tpo $depbase.Po In file included from genericups.c:24:0: genericups.h:147:4: error:

On Oct 24, 2015, at 12:11 PM, Walter Literowich <wliterow at gmail.com> wrote: > > Making all in drivers > make[1]: Entering directory '/cygdrive/c/nut/drivers' > gcc -g -O2 -Wall -Wsign-compare usbhid-ups.c -o usbhid-ups > In file included from usbhid-ups.c:32:0: > main.h:4:20: fatal error: common.h: No such file or directory > #include

On Oct 23, 2015, at 4:18 PM, Walter Literowich <wliterow at gmail.com> wrote: > > Making all in drivers > make[1]: Entering directory '/cygdrive/c/nut/drivers' > gcc -g -O2 -Wall -Wsign-compare usbhid-ups.c -o usbhid-ups > In file included from usbhid-ups.c:32:0: > main.h:4:20: fatal error: common.h: No such file or directory > #include "common.h"

....just a hunch... http://www.cs.nyu.edu/rgrimm/teaching/fa05-oop/windows-make.html -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20151102/383f1739/attachment.html>

Roger, My clients are not comfortable with using the terminal commands to check the UPS status. They are converts from Windows and have little or no exposure to entering commands into a command line interface. The output in the GUI is what they have come to expect from software and they can launch via a click on an icon on the launcher as opposed to remembering a command. 73 & Cheers, Ken

Hi all, we should have been found the problem. Attach the patch inclusive of this problem and the previous (Riello IDG400 wrong values & not powering off). Best regards, -----Messaggio originale----- Da: Nut-upsdev [mailto:nut-upsdev-bounces+e.parisi=riello-ups.com at lists.alioth.debian.org] Per conto di nut-upsdev-request at lists.alioth.debian.org Inviato: mercoled? 7 marzo 2018 13:03 A:

please tell me how i can use the hyperterminal to calibiration of my ups sua 1000VA. nut-upsdev-request@lists.alioth.debian.org wrote: Send Nut-upsdev mailing list submissions to nut-upsdev@lists.alioth.debian.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev or, via email, send a message with subject or body

Hi Arnaud, attached there are a new patch (fixed ups.upspower.nominal in GPSER protocol and device.mfr) and three devdumps. Let me know if this time all is correct, Elio Parisi. Elio Parisi Centro Ricerche RPS SpA Viale Europa, 7 37045 Legnago VR Tel. +39 0442 635811 Fax. +39 0442 635934 Skype Id: - Voip: E-mail: E.Parisi at riello-ups.com Web: www.riello-ups.com

1 - its on load blinking battery LEDs and not giving proper back up time . APC sua1000i nut-upsdev-request@lists.alioth.debian.org wrote: Send Nut-upsdev mailing list submissions to nut-upsdev@lists.alioth.debian.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev or, via email, send a message with subject or body

>I'm afraid I am just the messenger - @bigon (Laurent Bigonville, on GitHub) is a Debian maintainer of NUT, and he was pointing out the >bug report filed with Debian: >https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738122 >With other drivers, we sometimes see the "did not claim interface 0 before use" error if a driver gets out of sync with its PID file, >and

Hello, thank you for the idea. I'm already behind the permission problem, which originally apeared, but I did overcome it by rules settings. this is the result for 'ls -l /dev/bus/usb/004/007': ---- crw-rw-rw- 1 root nut 189, 390 pro 23 13:23 /dev/bus/usb/004/007 ---- Os is Debian 6.0.5 Squeeze Regards Dee Dne 22.12.2014 v 13:01 nut-upsdev-request at lists.alioth.debian.org

What is going on here? Someone has been posting their password for the nut-commits list to the nut-upsdev list. -- Peter nut-commits-request@lists.alioth.debian.org wrote: > > Welcome to the Nut-commits@lists.alioth.debian.org mailing list! > > To post to this list, send your email to: > > nut-commits@lists.alioth.debian.org > > General information about the mailing

My personal experience with a number of UPSes that are monitored via USB cable is that communications errors such as the ones referenced in the issue you linked to below are a result of USB hardware incompatibilities between the USB chipset and the USB port on the motherboard.*? This is NOT specific to the NUT project as it affects both apcupsd and in fact, has been reported as an issue with

ls -lia /<path>/wall will give you the owner and group . . . . Messages off . . . I think you are on the path . . . . -Tim On July 15, 2015 10:00:51 PM CDT, john hart <jsamcr at yahoo.com> wrote: >Time, not sure who owner is, but I've tried as both admin and myself, >to no avail. ?However, I told you that mesg is y, buti tried to send a >mesg using ?' write '

Rob, My suggestion is using the SEC2400 protocol. It's very simple, complete and based in text using using the idea of requesting and responsing. In the NUT software the name of the driver that manage this protocol is "gamatronic". Below the documentation: http://networkupstools.org/protocols/sec.html http://networkupstools.org/protocols/sec-protocol.html

Who is the owner and group for wall? Note that it is set group ID to allow it to write to sessions . . . thus, that owner needs to be a system account that can write to devices, not just Joe-Bob . . . You might also try 'strace wall' to see what it is trying to do. - Tim On July 15, 2015 9:48:32 PM CDT, john hart <jsamcr at yahoo.com> wrote: >Tim, >Thanks for the feedback.

Also, which version of NUT is involved? There were recently PRs (merged to master-branch, eventually will be in 2.8.1) about more SNMP-UPS support including APCs e.g. 1674, 1679, 1113 (should be in 2.8.0)... Many distros still ship 2.7.4... Jim On Tue, Feb 28, 2023, 00:57 Greg Troxel <gdt at lexort.com> wrote: > mateuszx via Nut-upsdev <nut-upsdev at alioth-lists.debian.net>