similar to: Building NUT under Windows

Hello all, After a hectic month in private life, as a byproduct I've got a viable merger of last released NUT 2.6.5 based Windows-ready codebase (thanks to the giants active a dozen years ago, on whose shoulders I stood today) and modern 2.8.x/master, fixing the merge conflicts and build warnings. Some details were tracked in discussion of https://github.com/networkupstools/nut/issues/5

I get the following error on r809 (but it looks like the code change happened here). Does HIDDevice_t need to be defined/changed in one of the headers? if gcc -DHAVE_CONFIG_H -I. -I../../drivers -I../include -I../../include -DDBUS_API_SUBJECT_TO_CHANGE -I/usr/include/hal -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -DINET6 -O2 -D_REENTRANT -DNETSNMP_USE_INLINE -Wall -Dlinux -I.

Windoze in da NUT house! Codebase of the NUT for Windows branch was merged to main codebase, not in the least to avoid bit-rot and need for resynchronisation with merge conflicts that regularly arose as the two branches "just co-existed". More community work is needed to complete some drivers' functionality and MSI package delivery, but for many use-cases it may already "just

Folks, while I've got the above combination to compile and run under Solaris 10, it seems that there are still problems in the libusb/ugen driver stack from Sun and or the APC Smart UPS 1500, so things aren't actually working. It seems that the APC Smart UPS 1500RM doesn't return the HID descriptor length information in 0x21 as noted in a previous thread, but in my case, it also

I finally took some time to lay down a consolidated roadmap to the next major milestone (2.4), and some update on this. 1) new documentation (User and Developer Manuals) -------------------------------------------------------------------------------------- This is the biggest change for 2.4. We will use the new test.networkupstools.org website to create and maintain the content, based upon the

> ---------- 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

On 2/27/07, A.Lizard <alizard@ecis.com> wrote: > terrarium:/home/alizard# /usr/local/ups/bin/newhidups -DDD -a belkin-ups > Network UPS Tools: 0.28 USB communication driver 0.28 - core 0.30 (2.0.5-pre2) > > debug level is '3' > Checking device (050D/0551) (002/006) the '002/006' part is "bus->dirname, dev->filename" in libusb.c. Does

Hello all, After a hectic month in private life, as a byproduct I've got a viable merger of last released NUT 2.6.5 based Windows-ready codebase (thanks to the giants active a dozen years ago, on whose shoulders I stood today) and modern 2.8.x/master, fixing the merge conflicts and build warnings. Some details were tracked in discussion of https://github.com/networkupstools/nut/issues/5

"Good news, everyone!" With CI builds of the branch now regularly passing on both the multiplatform FOSS NUT CI farm (including linux+mingw cross-builds), and CircleCI with MacOS, and newly on AppVeyor with Windows+MSYS2 (including integration tests with live upsd and some dummy-ups instances), after ironing a few wrinkles I intend to PR and merge it into the main NUT codebase soon,

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

On Apr 25, 2013, at 9:42 AM, Christian Wiese wrote: > I created a pull request #27 which is fixing the issue. > > # nut-scanner -qNU > [nutdev1] > driver = "usbhid-ups" > port = "auto" > vendorid = "051D" > productid = "0002" > product = "Back-UPS ES 700G FW:871.O2 .I USB FW:O2" > serial = "5B1243T01934"

Dear R-devel, I installed R-2.9.1 on the 'y:' drive which happens to be mounted to an IBRIX file system. I also downloaded and installed the Rtools bundle recommended for 2.9x. When I build a source package launching R via RGui.exe it seems to work fine: ## setting path according to "Appendix E The Windows toolset" >

FWIW, there is precedent with libusb{1,0}, libshut and libhid which abstract NUT operations from a "backend lib" to build against; similar for serial.c used by many drivers. Take care to not conflict by filenames with "real" third-party libs used by the build - especially to avoid mixups for headers and in docs/discussion. Jim On Thu, Feb 23, 2023, 22:16 MODRIS B?RZONIS

On Thu, Dec 4, 2008 at 4:51 PM, Arjen de Korte <adkorte-guest at alioth.debian.org> wrote: > Author: adkorte-guest > Date: Thu Dec 4 21:51:28 2008 > New Revision: 1596 > > Log: > Added new richcomm_usb driver based on the lakeview_usb driver (using libusb). Sorry if I wasn't clear - I was advocating *renaming* the lakeview_usb driver to richcomm_usb. Is there another

On Dec 31, 2009, at 8:45 AM, Arjen de Korte wrote: > Author: adkorte-guest > Date: Thu Dec 31 13:45:16 2009 > New Revision: 2218 > > Log: > Add pkg-config as method to retrieve CFLAGS and LDFLAGS (but fall > back to libusb-config) > > Modified: > trunk/m4/nut_check_libusb.m4 Arjen, I'm not sure you want parentheses in the shell script fragments. Search for

Arnaud, this commit refers to files called libshut.c and libshut.h, yet no such file has been added to SVN. Perhaps take this opportunity to run "svn status" and check for other files that might be missing from SVN. -- Peter > ---------- Forwarded message ---------- > From: Arnaud Quette > To: nut-commits@lists.alioth.debian.org > Date: Fri, 16 Jun 2006 13:40:59 +0000

Back from vacations, and before I dive into real-life work, I went over some ideas and notes from the NUT for Windows effort. Now they should be tracked at https://github.com/orgs/networkupstools/projects/2/views/1 and community help is welcome :) I probably forgot or missed some caveats - so feel free to post issues for this project if you think of some more... Jim On Thu, Jun 23, 2022, 23:52

Howdy, I had this working with lots of help for a developer before (Charles Lepple), but after upgrading to a somewhat more current version of FreeBSD the patched-up version stopped working. Seeing as this was more than a few years ago, I thought I'd give a new libusb and NUT a try to see if it might work out of the box. So far, no luck. Some info: FreeBSD 6.3 libusb 0.1.12 NUT 2.4.1

Hello, I've recently bought two cheap UPS (http://www.ldlc.com/fiche/PB00109242.html). They're not supported natively by NUT (even though the monitoring software is UPSilon from megatec). After some investigation, they almost use the krauler-type communication already supported in the blazer_usb driver. However, the UPS won't reply if the language ID is not 0x4095... Therefore, I

[please keep the discussion on the nut-upsdev list. thanks!] On Jan 30, 2014, at 10:20 AM, Jos? Sosa wrote: > Dear Mr. Lepple > > I am Leonardo Sosa and I am watching this issue with Rodolfo and Ronaldo. (in copy) > > See below our answers of your questions. > > What should I do now in order to include our code sgs_command in your code blazer_usb.c? As I mentioned to