Nut upsdev - Jan 2026 - Hoping for a new NUT release soon, testing welcome

Hello all,

  With FOSDEM coming up, and a lot of refactoring, feature and recipe
improvements merged since August, I hope to cut a new NUT v2.8.5 release in
about a week's time. That is, if your testing of the current master branch
would not come up with any show-stoppers and regressions ;) especially
regarding packaging (at least that re-done in the old manner - with new one
being recent introduction of a way to build NUT with private shared
libraries, typically reducing the installed footprint by 2x or more).

  Peruse the UPGRADING.adoc for changes that might bite (and NEWS.adoc for
changes overall).

  I'll try to push out a v2.8.1-rc1 tag to see how CI likes it tomorrow,
but the current master is all-green as far as dev iterations go.

Thanks in advance to all testers,
and big thanks to the many contributors of this cycle,
Jim Klimov
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20260121/7ebe2f9e/attachment.htm>

I'm working on updating the pkgsrc package using a "make dist"
output.

Mostly things are fine so far.


I suspect we just see things differently, but I would like to see far
far fewer complicated defaults, and more alignment of defaults with
autoconf norms.  It feels like too much magic and too much "nut is
special".   Basically, do it the autoconf way and people can set vars to
change and that's fine.

Packaging systems are set up to pass standard autoconf args to do things
that packaging system way.  So it's much less of a burden than you
think, and if someone is building themselves, they should  be using a
prefix that does not belong to a packagign sytem anyway.

random other notes:

  First, looks like a huge amount of work and ton of cleanups and
  improvements.  Yay!


  NEWS has a bunch of "expected".  If the release is closer than 2
weeks
  that has to stop!  Seriously, are we in feature freeze, headed to
  release, or are we not?  I'm ok either way, but trying to get things
  in and get a release out for an artificial non-deadline is just asking
  for a mess.   If it's just "move those to the next release
section",
  that's fine.


  NEWS says:
     For ages, most recipes for building NUT had customized the `sysconfdir` to
     be `/etc/nut`, which is not exactly the *system* configuration
     directory.
  but this is wrong.  sysconfdir is for the autoconf-user to say where
  they want config files for *this program*.
   
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/html_node/Installation-Directory-Variables.html
  and it is normal for packaging systems to use the standard place and a
  subdir.   I see this as a lot of complexity and churn and I am not
  sure it helps anyone.

  --with-confdir-examples: glad to see it!

  This change seems to just make it harder to reason about what happens:
     * The `configure` script would now probe (if it can) the operating systems
     for more user and group account names, such as `upsmon`, `nutmon`, `ups`,
     `nut` (last hit wins, separately for user and groups accounts) settling
     on one of those if detected instead of `nobody` (and optionally `nogroup`).
     It would also warn if `nobody` or `nogroup` end up being used for a build.
     [#3173]
  I don't remember previous defaults because pkgsrc passes the arg (and
  thus it won't matter), but I would vote for "if --with-user not
  passed, default to nut, and if that doesn't exist, error out".  Then
  people will set it how they want, and all will be well, with higher
  probabilty and less magic -- magic that seems to me more likely to be
  wrong than right.  Basically reliability is most important.

I know those are gripes but so far no real trouble.

I am running 2.8.4.1239-1239+gc49aa0e92 as built via pkgsrc from a
tarball I make disted from git, on two NetBSD-9 amd64 machines with a
Best Fortress LI660 (serial), and upsc is getting good data.

I am carrying a couple of patches in pkgsrc, but didn't need them in
git.  I will go over them and post; would be good to at least consider
upstreaming them.

The one I know needs applying:

----------------------------------------
$NetBSD$

Remediate bash ==.

Reported upstream by email 20260124 (or 25).

--- tests/nut-driver-enumerator-test.sh.orig	2026-01-27 00:24:21.471437853 +0000
+++ tests/nut-driver-enumerator-test.sh
@@ -614,7 +614,7 @@ testcase_semver_compare() {
 
     run_testcase_generic callSEMVERCMP \
         "SEMVER comparison helper: shell-style maths: (non-)equality with
added trailing zero value e.g. 3 vs 30" 1 "" \
-        test 01.02.03 == 1.002.00030
+        test 01.02.03 = 1.002.00030
 
     run_testcase_generic callSEMVERCMP \
         "SEMVER comparison helper: shell-style maths: non-equality with
added trailing zeroed components (and different leading zero pads)" 1
"" \

I have built, run tests, make dist, and used that in pkgsrc, and
installed a binary package on netbsd-9 amd64, and live tested with a
Best Fortress LI660 and it seems good.

What I tested was

  commit 9275ebedea609cdcd14b726283aee3b1d8b24b7f (HEAD -> master,
upstream/master, upstream/HEAD)
  Author: Jim Klimov <jimklimov+nut at gmail.com>
  Date:   Mon Feb 2 15:23:21 2026 +0100

which is 19 commits ahead of v2.8.5-rc3.


(It does not appear we have really reached rc as there is a rapid rate
of commits; this is really a beta situation.  But I'm ok with testing
once a week, or on demand if we have truly arrived at an RC, meaning no
changes unless they fix a regression from 2.8.4!)