[Nut-upsuser] Where is nut-scanner on raspberry pi?

[Jim Klimov]

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
PRs).

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:
>
>   OPTIONS:
>     -C, --complete_scan: Scan all available devices except serial ports
> (default).
>   * 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
> detected.
>   * 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
> support)
> _______________________________________________
> Nut-upsuser mailing list
> Nut-upsuser at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20220814/56d9ec8f/attachment.htm>