[Nut-upsuser] UPS configuration issue?

Wed May 14 12:16:22 BST 2025

This sub-thread is veering off-topic from the original question... but I'll
digress.

>> However debian's legendary slowness to update things does test my
>> patience at times. The fact that bookworms default nut is 2.8.0 is an
>> example.

Per https://www.debian.org/News/2023/20230610 they released the 12th
(bookworm) baseline on June 10, 2023, and `bookworm will be supported for
the next 5 years` (after handing off to community after first 3 years, per
https://wiki.debian.org/LTS).

The packages that go in a new release are finalized a couple of months
(give or take) before the stable release.

Per https://networkupstools.org/, git tags and whatnot, "Apr 26, 2022: NUT
2.8.0 released" and "Oct 31, 2023: NUT 2.8.1 released" - so at the time
they had no other NUT to put into the baseline than the newest (at the
time) 2.8.0. And it's great they made the effort and did not ship 2.7.4
again :D

As I said before, "Stable" may mean "stale", but primarily it is
"unexciting" - no cutting edge features, but also no surprises and bugs for
you being the first to discover after a couple of years of use and interim
minor updates. It is not only about lack of volunteer time (and as the
adage goes, staying on the outside and donating a bit sometimes can not
help the people doing actual work in addition to a dayjob, to run longer
sleepless nights or stretch longer family-outing-less weekends), but also a
matter of policy when you name something a stable distro lineage. This
inclination to minimal change (focusing only on bug fix backports) is
precisely what makes it stable.

People who want a more dynamic workstation or server can build their own,
add repos for specific newer packages (either way, making software combos
that distros can not test as a near-infinite matrix - so it is a mix of
luck and API stability that keeps these mostly working in practice) or
fully stay on an "experimental" or "sid" repository instead of a particular
stable release, etc.

If you go with a fully experimental distro, do however expect the OS
architecture to change often and break things (let's introduce systemd!
let's just drop python2 and see what misses it! let's cleanly separate
32-bit and 64-bit libs/bins into separate paths, packages and dependency
trees! let's change versioned toolkit naming patterns!). Part of why you
are on it is to give early feedback after all - so that for millions of
people on the next stable release that sails from this whirlwind, it "just
works" out of the box ;)

BYO became something we have to encourage with NUT bug reports/suspicions
made against older releases, and many man-months went into documenting and
automating in-place rebuilds and recipe performance+stability to make it
easier for "laymen". After all, a NUT release is also "stale" a few days
after the cut-off point, as new features and bug fixes begin pouring in.

Part of that was collecting the piecemeal answers to questions here and
there into the
https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests
article, to flex this link around :)

> one final suggestion. incorporate into your sig, a download address,
making an update a 1 click process to pull a fresh tarball.

That is an interesting idea, but at the moment the new tarballs appear all
too rarely (a github source of the master branch is more relevant), and for
people doing an update it would not be a "1 click process" with the build
environment setup involved anyway :)

And there's a long stack of links to NUT Website docs section, download
section, github wiki, etc. which would make a simple every-mail signature
cumbersome:

* https://networkupstools.org/download.html
* https://github.com/networkupstools/nut/releases
* https://github.com/networkupstools/nut/wiki and the dozen of quick-links
from its start page
* https://networkupstools.org/documentation.html

But I'll keep that thought to figure something out eventually, thanks.

> However when 2.8.3 is out, I might give it a shot

As a git tag and tarball, it is already out, for almost a month :)

There were about 6 attempts to get there, every time thinking "oh now
there's the final release" and ending up with a candidate, until one of
those did not raise questions and became the release too. And apparently
there still remains a recently discovered bug about (usbhid-ups) shutdowns,
introduced after 2.8.2 and not found as community's (and my own)
pre-release testing focused on seeing info from the devices.

In the context of distros, I am not sure which approach would be better -
to only expose the problem so they can maybe notice and issue fixed
packages with a small patch, or also try to push things planned for a next
NUT release to happen in an even later version, and speed up cutting off a
2.8.4 so soon after a 2.8.3. Wouldn't be unthinkable - some rework done but
delayed "until after 2.8.3" was merged, and some new drivers appeared, so
even an incomplete month later there is already substantial change worthy
of a release. Apparently that gets more eyes looking at the code than
pre-release rallies arranged via the mailing lists, and some logic is only
really tested by the release routine itself. :\

> ... if I can actually get Jim's output.

@gene : this one I am not really sure about - what did you mean? :)

Probably related to this part from an earlier message?

> I have an APC 1500wa, now several years old.  Its front panel display has
been asking for a new set of batteries for at least 5 years...

At least PbAc batteries do age, seem to have a common lifetime of about 3
years (5-10 with some special tech and non-consumer pricing).
In earlier life, I've had smaller desktop APCs beeping for new batteries
every couple of years (rack ones were not as annoying), and they were
glorified power strips until the replacement (turned off immediately when
wall power disappeared).

> And nut is not running, fails to start since bookworm.  And I have NDI
why.

This is probably "Jim's output" you meant - but without logs it really is
hard to say. There might be bugs of packaging, or of NUT, or some
mis-configuration...

Hopefully
https://github.com/networkupstools/nut/wiki/Changing-NUT-daemon-debug-verbosity
can get you started about the new ways of debug log collection with systemd
involved (and NUT 2.8.x abilities about configuring or even
"command"'ingthe debug level instead of fiddling with command lines in
init-scripts), but I think that would certainly warrant starting a new
thread on the list :)

Hope this helps,
Jim Klimov

On Wed, May 14, 2025 at 4:20 AM gene heskett via Nut-upsuser <
nut-upsuser at alioth-lists.debian.net> wrote:

> On 5/13/25 21:05, Sam Varshavchik wrote:
> > gene heskett via Nut-upsuser writes:
> >
> >> However debians legendary slowness to update things does test my
> >> patience at times. The fact that bookworms default nut is 2.8.0 is an
> >> example.
> >
> > That sounds familiar. Debian's been shipping very old versions of my
> > packages, which was …irritating. I am not being accusatory, I
> > understand that it's all volunteer work, and most of the time …there
> > was no volunteer. But it was still a problem for me.
> >
> > I solved this problem by boning up, learning how to create deb
> > packages, then including a script in my tarballs that create deb
> > packages from their own tarballs – very similar to how including a
> > package.spec in the tarball allows rpmbuild to build installable rpms
> > directly from the tarball: "rpmbuild -ta package-version.tar.bz2", sit
> > back, and wait for the binary rpms to be created.
> >
> > As far as I know debuild doesn't have anything comparable to this, but
> > what I hacked up came pretty close. The report from the field was that
> > non-developers are able to use it. And this solved the "old packages
> > in Debian" issue and made it go away, for the most part. I only made
> > sure that what I did was not going to interfere with anything a real,
> > honest to goodness, Debian or Ubuntu maintainer needs to do, so when
> > one shows up, occasionally, from time to time, it stays out of their way.
> >
> > Unfortunately this is not something that works generically, the script
> > is tailored specifically to the tarball's contents. But that's the
> > general solution to addressing old stuff in Debian or Ubuntu.
>
> Well i have been in the past, able to build from the tarballs but will
> readily admit that at 90 yo, its getting less and less appetizing.
> However when 2.8.3 is out, I might give it a shot if I can actually get
> Jim's output.  Or possibly switch distro's. Debian has about worn me
> out. I have a time wasting bug that no one on this ball of rock & water
> can duplicate.
>
> Thanks Sam V.
>
> >
> >
> > _______________________________________________
> > Nut-upsuser mailing list
> > Nut-upsuser at alioth-lists.debian.net
> > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
> Cheers, Gene Heskett, CET.
> --
> "There are four boxes to be used in defense of liberty:
>   soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author, 1940)
> If we desire respect for the law, we must first make the law respectable.
>   - Louis D. Brandeis
>
>
> _______________________________________________
> 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/20250514/b82aff8f/attachment.htm>