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

[Greg Troxel]

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>