Thanks for the update. On Wed, Mar 30, 2022, 17:55 Greg Troxel <[email protected]> wrote:
> > Jim Klimov <[email protected]> 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. >
_______________________________________________ Nut-upsdev mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
