<div dir="auto">Thanks for the report, sounds interesting.<div dir="auto"><br></div><div dir="auto"> Just went online to say that I'd like to release a NUT 2.8.0 (nee 2.7.5) soon, or at least an RC1 of that, so another round of community testing with current master (and reminders of what missed ideas better get in before release) would be great. And saw your message, must be hailing from the future :)<div dir="auto"><br></div><div dir="auto"> I'll try to spin a NetBSD VM to try some builds too.<div dir="auto"><br></div><div dir="auto"> One thing that pops up in your make log is that it looks into system includes before (some of) the source includes - and apparently sees an older NUT there to confuse things, e.g.:</div><div dir="auto"><br></div><div dir="auto">````</div><div dir="auto"><div dir="auto">gcc -DHAVE_CONFIG_H -I. -I../../drivers -I../include -I/usr/pkg/include -I../../include -I/usr/pkg/include/libusb-1.0 -I../../clients -isystem /usr/local/include -g -O2 -Wno-reserved-identifier -Wno-unknown-warning-option -std=gnu99 -Wno-system-headers -Wall -Wextra -Wsign-compare -pedantic -Wno-error -MT dummy_ups-dummy-ups.o -MD -MP -MF .deps/dummy_ups-dummy-ups.Tpo -c -o dummy_ups-dummy-ups.o `test -f 'dummy-ups.c' || echo '../../drivers/'`dummy-ups.c</div><div dir="auto">../../drivers/dummy-ups.c: In function ‘upsclient_update_vars’:</div><div dir="auto">../../drivers/dummy-ups.c:349:44: warning: passing argument 4 of ‘upscli_list_next’ from incompatible pointer type [-Wincompatible-pointer-types]</div><div dir="auto"> while (upscli_list_next(ups, numq, query, &numa, &answer) == 1)</div><div dir="auto"> ^</div><div dir="auto">In file included from ../../drivers/dummy-ups.c:41:0:</div><div dir="auto">/usr/pkg/include/upsclient.h:86:5: note: expected ‘unsigned int *’ but argument is of type ‘size_t * {aka long unsigned int *}’</div><div dir="auto"> int upscli_list_next(UPSCONN_t *ups, unsigned int numq, const char **query,</div><div dir="auto"> ^~~~~~~~~~~~~~~~</div><div dir="auto">../../drivers/dummy-ups.c: At top level: ...</div><div dir="auto">````</div><div dir="auto"><br></div><div dir="auto">Not sure if this is behind the eventual failure:</div><div dir="auto"><br></div><div dir="auto">````</div><div dir="auto"><div dir="auto">In file included from ../../../tools/nut-scanner/scan_usb.c:30:0:</div><div dir="auto">../../../tools/nut-scanner/nutscan-usb.h:22:10: fatal error: usb.h: No such file or directory</div><div dir="auto"> #include <usb.h></div><div dir="auto"> ^~~~~~~</div><div dir="auto">compilation terminated.</div><div dir="auto">````</div><div dir="auto"><br></div><div dir="auto">Maybe indirectly - e.g. if detection or use of certain libusb variant got confused.</div><div dir="auto"><br></div><div dir="auto"> For a bigger picture, NUT has a few large areas impacted by the libusb API or modeled after it, including some HID and SHUT libs and drivers. The two direct libusb APIs (0.1 and 1.0) differ notably in method arguments and data types used (witdth and sign of ints involved), so to simplify NUT codebase maintenance, those types were typedef'ed (and some similar methods aliased) and the platform differences are concentrated in nut_libusb.h, libhid.h and such, depending on configure-script choice of the library (and ifdef's are used there).</div><div dir="auto"><br></div><div dir="auto"> This approach was tested to work well with many generations of linux x86/arm and illumos/solaris distros vs. UPS HW; builds at least pass regularly on CI farms with freebsd, openbsd and macosx... So really curious what needs tuning for netbsd - hopefully some nuance and nothing major :)</div><div dir="auto"><br></div><div dir="auto">Jim</div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 30, 2022, 04:46 Greg Troxel <<a href="mailto:gdt@lexort.com">gdt@lexort.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
In December you asked for testing, and I am not able to cope with doing<br>
so.<br>
<br>
I'm trying to test on NetBSD 9 amd64. 2.7.4 works fine with a few<br>
patches, that I'll see about upstreaming after I get a build from git<br>
working.<br>
<br>
I am using branch master from git@github.com:networkupstools/nut.git<br>
<br>
autogen and configure go ok.<br>
<br>
With the build, I have two syndromes:<br>
<br>
* libusb1 installed, libusb0 not installed<br>
<br>
code tries to include usb.h and this is I think the old interface<br>
<br>
* libusb1 installed, libusb-compat also installed (provides libusb0 headers)<br>
<br>
../../../tools/nut-scanner/scan_usb.c:38:29: error: unknown type name ‘libusb_device_handle’; did you mean ‘usb_dev_handle’?<br>
static int (*nut_usb_close)(libusb_device_handle *dev);<br>
^~~~~~~~~~~~~~~~~~~~<br>
usb_dev_handle<br>
<br>
so I wonder if the "use libusb1" code path is really finished.<br>
<br>
<br>
In reading nutscan-usb.h, it seems to just include usb.h, not ifdefed on<br>
which version.<br>
<br>
Here's a radical question: is it really necessary to support libusb 0?<br>
I am guessing we want new nut to be buildable on really old systems.<br>
<br>
But I don't understand why there isn't a #if HAVE_LIBUSB_H switch on<br>
things. I admit to being fuzzy on the glorious complexity of libusb<br>
0/1.<br>
<br>
_______________________________________________<br>
Nut-upsdev mailing list<br>
<a href="mailto:Nut-upsdev@alioth-lists.debian.net" target="_blank" rel="noreferrer">Nut-upsdev@alioth-lists.debian.net</a><br>
<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev" rel="noreferrer noreferrer" target="_blank">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev</a><br>
</blockquote></div>