Add UPower support to nut-scanner

[timn]

• Added support for scanning UPower devices via GDBus/libgio.
• Implemented dynamic loading of libgio/libglib to avoid hard dependencies.
• Added --upower_scan (-J) option to nut-scanner.
• Added m4/nut_check_libglib.m4 to detect GLib/GIO.
• Updated configure.ac to check for UPower support requirements.
• Updated nut-scanner build system and initialization.
• Updated nut-scanner man page

Tested locally with nut-upower driver on Fedora 43 (direct scanning with -J).

General points

• Described the changes in the PR submission or a separate issue, e.g.
  known published or discovered protocols, applicable hardware (expected
  compatible and actually tested/developed against), limitations, etc.

• There may be multiple commits in the PR, aligned and commented with
  a functional change. Notably, coding style changes better belong in a
  separate PR, but certainly in a dedicated commit to simplify reviews
  of "real" changes in the other commits. Similarly for typo fixes in
  comments or text documents.

• Please star NUT on GitHub, this helps with sponsorships! ;)

Frequent "underwater rocks" for driver addition/update PRs

• Revised existing driver families and added a sub-driver if applicable
  (nutdrv_qx, usbhid-ups...) or added a brand new driver in the other
  case.

• Did not extend obsoleted drivers with new hardware support features
  (notably blazer and other single-device family drivers for Qx protocols,
  except the new nutdrv_qx which should cover them all).

• For updated existing device drivers, bumped the DRIVER_VERSION macro
  or its equivalent.

• For USB devices (HID or not), revised that the driver uses unique
  VID/PID combinations, or raised discussions when this is not the case
  (several vendors do use same interface chips for unrelated protocols).

• For new USB devices, built and committed the changes for the
  scripts/upower/95-upower-hid.hwdb file

• Proposed NUT data mapping is aligned with existing docs/nut-names.txt
  file. If the device exposes useful data points not listed in the file, the
  experimental.* namespace can be used as documented there, and discussion
  should be raised on the NUT Developers mailing list to standardize the new
  concept.

• Updated data/driver.list.in if applicable (new tested device info)

Frequent "underwater rocks" for general C code PRs

• Did not "blindly assume" default integer type sizes and value ranges,
  structure layout and alignment in memory, endianness (layout of bytes and
  bits in memory for multi-byte numeric types), or use of generic int where
  language or libraries dictate the use of size_t (or ssize_t sometimes).

• Progress and errors are handled with upsdebugx(), upslogx(),
  fatalx() and related methods, not with direct printf() or exit().
  Similarly, NUT helpers are used for error-checked memory allocation and
  string operations (except where customized error handling is needed,
  such as unlocking device ports, etc.)

• Coding style (including whitespace for indentations) follows precedent
  in the code of the file, and examples/guide in docs/developers.txt file.

• For newly added files, the Makefile.am recipes were updated and the
  make distcheck target passes.

Caveat: I do not have powerman libs available and distcheck fails without them (I think I didn't have this with the earlier PR, not sure if behavior changed or if I missed it). But I can build nut-scanner and use when running autogen/configure myself.

General documentation updates

• Updated docs/acknowledgements.txt (for vendor-backed device support)

• Added or updated manual page information in docs/man/*.txt files
  and corresponding recipe lists in docs/man/Makefile.am for new pages

• Passed make spellcheck, updated spell-checking dictionary in the
  docs/nut.dict file if needed (did not remove any words -- the make
  rule printout in case of changes suggests how to maintain it).

Additional work may be needed after posting this PR

• Propose a PR for NUT DDL with detailed device data dumps from tests
  against real hardware (the more models, the better).

• Address NUT CI farm build failures for the PR: testing on numerous
  platforms and toolkits can expose issues not seen on just one system.

• Revise suggestions from LGTM.COM analysis about "new issues" with
  the changed codebase.

[AppVeyorBot]

✅ Build nut 2.8.4.4136-master completed (commit 69d9fbe737 by @timn)

[jimklimov]

Thanks, looks quite comprehensive! I hope the CI nits will not pester you for too many cycles :)

I think the library version in tools/nut-scanner/Makefile.am should be bumped, not sure OTOH which component(s) - see docs linked from a comment near there. As you just add new symbols, backwards-compatibility number component can also be bumped I think.

[jimklimov]

I think the -isystem fix for includes got lost here?

[jimklimov]

I think in your last round of commits, the m4 change to conflate build args and varnames of GLIB and GIO was a step back, and CI is crashing again. Did you write that change, or some Copilot? Did you review it then before pushing to the PR source branch? :)

I appreciate the pedantic hardening about xcalloc() pointer casting, indentations, C++ refinement, etc. but that really belongs in another PR - the relatively few changes that are actually related to nut-scanner are lost in the ever-updating wall of text. Also those changes are likely to just pass CI and get merged faster than when co-bundled with this one and we keep waiting another half a day for the thousands of builds to pass... or not :)

If this PR change is nearing the end (after fixing the m4 to what allegedly worked 3 commits ago), I don't require to cut it apart just for the sake of that (hey, less load on CI farm to hunt for two birds at once), but consider this in future ones.

UPDATE: Sorry I didn't before, but now read into your commit comments and why those clean-ups appeared. Thanks in fact for building and testing on the bleeding edge :) Still, maybe if that imperfection was found earlier, the clean-up could be a prerequisite PR :D

[jimklimov]

Hopefully this step-back, step-forth will cover the -isystem again :)

[timn]

Thanks. I wanted to see if the closer alignment to the other change would still be sufficient on the build farm (regarding -isystem), so that maintenance would be easier. Seemingly it's not :-)

If you want I can still pull out the other changes. It's just that without those I couldn't test my actual changes on my target system, as they would consistently fail. I read your update as "leave them in this time", if that assumption is wrong let me know and I'll split it up. I'll look into the remaining build fails now.

[jimklimov]

I guess can let it be a big commit so far. For GHA, one nit popped up:

scan_avahi.c: In function 'wrap_nut_avahi_client_new':
scan_avahi.c:602:83: error: implicit conversion from 'enum <anonymous>' to 'AvahiClientFlags' [-Werror=enum-conversion]
  602 |         return (*nut_avahi_client_new)((*nut_avahi_simple_poll_get)(simple_poll), (AvahiLookupFlags)0, client_callback, NULL, error);
      |                                                                                   ^~~~~~~~~~~~~~~~~~~
  CXX      cppunittest-cpputest.o
At top level:
cc1: note: unrecognized command-line option '-Wno-unknown-warning-option' may have been intended to silence earlier diagnostics
cc1: note: unrecognized command-line option '-Wno-reserved-identifier' may have been intended to silence earlier diagnostics
cc1: all warnings being treated as errors

Not sure right now (at a conf and batteries dying) if these are due to CFLAGS changes or refinements.

[timn]

I guess can let it be a big commit so far. For GHA, one nit popped up:

Ok.

Not sure right now (at a conf and batteries dying) if these are due to CFLAGS changes or refinements.

Na, I just picked the wrong enum to cast to in that instance. Fixed in the last commit.

[AppVeyorBot]

✅ Build nut 2.8.4.4148-master completed (commit bb661c82b9 by @jimklimov)

[AppVeyorBot]

❌ Build nut 2.8.4.4149-master failed (commit 943c323d27 by @timn)

[jimklimov]

I guess scan_upower.c (like many other spot earlier) should move from ifdef WITH_XXX to if defined XXX && XXX pattern, as we lately tend to get such toggles defined as zero (so ifdef passes). I see some nearby files guilty of that too, so will post a commit on that. Probably they pass on CI farm and packager's machines because they do have everything that nut-scanner build needs at once :D

Also going over the tons of small changes, see some good catches there (even an occasional xmalloc() of a wrong struct's size), some odd ones (null-check for xmalloc returns that should never happen, but hey better safe than sorry), and very odd (like "what if configfile is not null at the start of main()?")

This one seems fun:

- pass = (sem_trywait(semaphore) == 0);
+ pass = (sem_trywait(semaphore) == 0) ? TRUE : FALSE;

...but gets one thinking: what if someone redefines the macro values of TRUE and FALSE? :)

It also struggled with indentations (adding spaces instead of tabs sometimes, usually with two or more layers deep, but not consistently).

It is interesting to take apart the workings of an alien mind ;-)

[AppVeyorBot]

❌ Build nut 2.8.4.4160-master failed (commit 5eea31a877 by @jimklimov)

[AppVeyorBot]

❌ Build nut 2.8.4.4176-master failed (commit 33596189eb by @jimklimov)

[AppVeyorBot]

✅ Build nut 2.8.4.4177-master completed (commit df197a1977 by @jimklimov)

[timn]

Thanks for putting in the effort! It seems now it's waiting to see if the CI is happy. This week is packed so I can join in only on the weekend if more work is necessary.

[timn]

This one seems fun:

- pass = (sem_trywait(semaphore) == 0);
+ pass = (sem_trywait(semaphore) == 0) ? TRUE : FALSE;

It is interesting to take apart the workings of an alien mind ;-)

That was my "alien mind" 😅 The thing is it's not "true" and "false" but custom enums, so technically it's a wrong assignment.

[jimklimov]

Oh, thanks for clearing that up (facepalm) :)
I hope thia gets merged before the weekend, but thanks for the offer and a pretty solid changeset.

BTW, which system offers clang-21 now? Might want one in the build matrix...