[Nut-upsuser] Where is nut-scanner on raspberry pi?
jimklimov+nut at gmail.com
Sun Aug 14 16:54:16 BST 2022
Posted https://github.com/networkupstools/nut/issues/1560 lest we forget :)
On Sun, Aug 14, 2022, 02:06 Jim Klimov <jimklimov+nut at gmail.com> wrote:
> Haven't poked INSTALL.nut for a while, PRs welcome. And there were many
> bite-size PR ideas in this thread ;)
> There was quite a bit of details poured into docs/config-prereqs.txt that
> grew along with CI farm over the past year or two, so covers many OSes
> (even Windows, it its branch).
> From my stunt at packaging NUT for some in-house stuff and researching
> others' work, the approach I saw often was to `configure --with-all` and
> add `--without-something` for components utterly missing on a particular
> OS. Then the resulting binaries are assigned to this or that package to
> group drivers by dependencies, clients, tools, etc.
> The help text posted above seems to be from a system that lacks shared
> net-snmp, libusb, etc. which nut-scanner loads dynamically by design of its
> era, so it could be bundled freely and without impacting the binary file by
> strict links to shared objects. Worked for you in fact - libraries missing
> but tool does run for other protocols. A downside is dependency on lib file
> naming and location (master may be more flexible in that since last week's
> On Thu, Aug 11, 2022, 17:55 Greg Troxel <gdt at lexort.com> wrote:
>> It turns out that there is a bug in nut about this, in 2.8.0.
>> I checked the pkgsrc package, and it doesn't have nut-scanner. Usually
>> what is packaged is what upstream installs. On digging in, I found that
>> the package did not declare a dependency on libltldl and thus it was not
>> visibile during the build, and nut-scanner was not built.
>> The first bug is that this is not documented in INSTALL.nut. If it
>> were, it would be a package bug not to provide it. It is sort of hinted
>> at that somehwere else there is a list of prereqs, and I eventually
>> found them, but I think "this is what you need installed to build", even
>> if a pointer, should be front and center in a really-hard-to-miss way.
>> And, there is a huge list of per-OS, without first things being
>> described in terms of upstream package names in an
>> OS/distribution-agnostic manner.
>> The second bug is that the nut-scanner man page is installed even if
>> nut-scanner is not built. Probably the fix is to move man pages to be
>> with their programs so docs/code match, but that is surely a can of
>> worms and just conditionalizing it in the Makefile.am the same way that
>> the nut-scanner subdir is conditionalized is reasonable.
>> I changed pkgsrc to depend on libltldl and now I get nut-scanner. I'll
>> likely commit that change. But, the main nut package does not use usb,
>> and I haven't figured out how that works with the usb split package.
>> (I am not meaning to assert that nut-scanner does or does not belong as
>> default or that users should or should not use it.)
>> The nut-scanner I got doesn't seem that useful:
>> -C, --complete_scan: Scan all available devices except serial ports
>> * Options for USB devices scan not enabled: library not detected.
>> * Options for SNMP devices scan not enabled: library not detected.
>> * Options for XML/HTTP devices scan not enabled: library not detected.
>> -O, --oldnut_scan: Scan NUT devices (old method).
>> * Options for NUT devices (avahi method) scan not enabled: library not
>> * Options for IPMI devices scan not enabled: library not detected.
>> -E, --eaton_serial <serial ports list>: Scan serial Eaton devices
>> (XCP, SHUT and Q1).
>> -T, --thread <max number of threads>: Limit the amount of scanning
>> threads running simultaneously (not implemented in this build: no pthread
>> Nut-upsuser mailing list
>> Nut-upsuser at alioth-lists.debian.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Nut-upsuser