Jim Klimov
2022-Mar-30 15:35 UTC
[Nut-upsdev] [Nut-upsuser] LibUSB-1.0+0.1 testing wanted, NUT 2.7.5 pending
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>
Greg Troxel
2022-Mar-30 15:55 UTC
[Nut-upsdev] [Nut-upsuser] LibUSB-1.0+0.1 testing wanted, NUT 2.7.5 pending
Jim Klimov <jimklimov+nut at gmail.com> writes:> 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 :)Now that I'm set up doing test builds/reports is easier.> I'll try to spin a NetBSD VM to try some builds too.That would be great. I realize it has a lot fewer users than GNU/Linux but as I realize you know testing on a few disparate systems shakes out bugs that would manifest on a number of the next 20 not yet tested on.> 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.:Ah, I will look into this. I didn't realize I had nut installed; I'm doing test builds on a machine that's not my production server/upsd machine. If that is what's wrong, then it's a nut build system bug. It's very normal in the packaging world to have the old version install while building the new version. But it should be fairly easy to fix by moving the includes of things in nut sources to before all the configure and found includes.> Maybe indirectly - e.g. if detection or use of certain libusb variant got > confused.Anything seems possible; I posted because I was at a point in understanding the code where it suddenly got a lot harder.> 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).That makes sens.> 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 :)Given what you are running on already, it really seems like it has to be minor. The mystery is that tools/nut-scanner/nutscan-usb.h seems to have code for libusb0 hardcoded. It turns out that I had done a build without objdir back in October, and forgotten that. Doing an objdir build apparently used that old file, even though it seems like it should have been rebuilt. With my git tree totally cleaned ("git status --ignored" shows only _build which is a symlink to my build script), the build completed ok. Thanks very much for the hints; between your help and a fresh look I have a build and I understand better a small thing that's wrong. I'll start a new thread now that I can be coherent about the small thing. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: not available URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20220330/5606cb7c/attachment.sig>