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

[Jim Klimov]

Thanks for the update.

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

>
> 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 --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20220330/464c2ce0/attachment.htm>