[Nut-upsdev] [Nut-upsuser] LibUSB-1.0+0.1 testing wanted, NUT 2.7.5 pending

[Jim Klimov]

Thanks for the report, sounds interesting.

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

  I'll try to spin a NetBSD VM to try some builds too.

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

````
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
../../drivers/dummy-ups.c: In function ‘upsclient_update_vars’:
../../drivers/dummy-ups.c:349:44: warning: passing argument 4 of
‘upscli_list_next’ from incompatible pointer type
[-Wincompatible-pointer-types]
  while (upscli_list_next(ups, numq, query, &numa, &answer) == 1)
                                            ^
In file included from ../../drivers/dummy-ups.c:41:0:
/usr/pkg/include/upsclient.h:86:5: note: expected ‘unsigned int *’ but
argument is of type ‘size_t * {aka long unsigned int *}’
 int upscli_list_next(UPSCONN_t *ups, unsigned int numq, const char **query,
     ^~~~~~~~~~~~~~~~
../../drivers/dummy-ups.c: At top level: ...
````

Not sure if this is behind the eventual failure:

````
In file included from ../../../tools/nut-scanner/scan_usb.c:30:0:
../../../tools/nut-scanner/nutscan-usb.h:22:10: fatal error: usb.h: No such
file or directory
 #include <usb.h>
          ^~~~~~~
compilation terminated.
````

Maybe indirectly - e.g. if detection or use of certain libusb variant got
confused.

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

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

Jim

On Wed, Mar 30, 2022, 04:46 Greg Troxel <gdt at lexort.com> wrote:

>
> In December you asked for testing, and I am not able to cope with doing
> so.
>
> I'm trying to test on NetBSD 9 amd64.  2.7.4 works fine with a few
> patches, that I'll see about upstreaming after I get a build from git
> working.
>
> I am using branch master from git at github.com:networkupstools/nut.git
>
> autogen and configure go ok.
>
> With the build, I have two syndromes:
>
> * libusb1 installed, libusb0 not installed
>
>   code tries to include usb.h and this is I think the old interface
>
> * libusb1 installed, libusb-compat also installed (provides libusb0
> headers)
>
>   ../../../tools/nut-scanner/scan_usb.c:38:29: error: unknown type name
> ‘libusb_device_handle’; did you mean ‘usb_dev_handle’?
>     static int (*nut_usb_close)(libusb_device_handle *dev);
>                                 ^~~~~~~~~~~~~~~~~~~~
>                                 usb_dev_handle
>
> so I wonder if the "use libusb1" code path is really finished.
>
>
> In reading nutscan-usb.h, it seems to just include usb.h, not ifdefed on
> which version.
>
> Here's a radical question: is it really necessary to support libusb 0?
> I am guessing we want new nut to be buildable on really old systems.
>
> But I don't understand why there isn't a #if HAVE_LIBUSB_H switch on
> things.  I admit to being fuzzy on the glorious complexity of libusb
> 0/1.
>
> _______________________________________________
> Nut-upsdev mailing list
> Nut-upsdev at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20220330/8ff60d47/attachment.htm>