<div dir="ltr"><div>This sub-thread is veering off-topic from the original question... but I'll digress.</div><div><br></div><div>
<span class="gmail-im">>> However debian's legendary slowness to update things does test my <br>
>> patience at times. The fact that bookworms default nut is 2.8.0 is an <br>
>> example.</span>
<br></div><div><br></div><div>Per <a href="https://www.debian.org/News/2023/20230610">https://www.debian.org/News/2023/20230610</a> they released the 12th (bookworm) baseline on June 10, 2023, and `<q>bookworm</q>
will
be
supported for the next 5 years` (after handing off to community after first 3 years, per <a href="https://wiki.debian.org/LTS">https://wiki.debian.org/LTS</a>).</div><div><br></div><div>The packages that go in a new release are finalized a couple of months (give or take) before the stable release.</div><div><br></div><div>Per <a href="https://networkupstools.org/">https://networkupstools.org/</a>, 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</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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 ;)</div><div><br></div><div>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.</div><div><br></div><div>Part of that was collecting the piecemeal answers to questions here and there into the <a href="https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests">https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests</a> article, to flex this link around :)</div><div><br></div><div>
<div>>
one final suggestion. incorporate into your sig, a download address,
making an update a 1 click process to pull a fresh tarball.
<br></div><div><br></div><div>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 :)</div><div><br></div><div>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:</div><div><br></div><div>* <a href="https://networkupstools.org/download.html">https://networkupstools.org/download.html</a></div><div>* <a href="https://github.com/networkupstools/nut/releases">https://github.com/networkupstools/nut/releases</a></div><div>* <a href="https://github.com/networkupstools/nut/wiki">https://github.com/networkupstools/nut/wiki</a> and the dozen of quick-links from its start page</div><div>* <a href="https://networkupstools.org/documentation.html">https://networkupstools.org/documentation.html</a></div><div><br></div><div>But I'll keep that thought to figure something out eventually, thanks.
</div>
<br></div><div>>
However when 2.8.3 is out, I might give it a shot</div><div><br></div><div>As a git tag and tarball, it is already out, for almost a month :)</div><div><br></div><div>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.</div><div><br></div><div>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. :\</div><div><br></div><div>> ... if I can actually get Jim's output.</div><div><br></div><div>@gene : this one I am not really sure about - what did you mean? :)</div><div><br></div><div>Probably related to this part from an earlier message?</div><div><br></div><div>>
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...</div><div><br></div><div>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).</div><div>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).</div><div><br></div><div>> And nut is not running, fails to start since bookworm. And I have NDI why. <br></div><div><br></div><div>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...</div><div><br></div><div>Hopefully <a href="https://github.com/networkupstools/nut/wiki/Changing-NUT-daemon-debug-verbosity">https://github.com/networkupstools/nut/wiki/Changing-NUT-daemon-debug-verbosity</a> 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 :)</div><div><br></div><div>Hope this helps,</div><div>Jim Klimov</div><div><br></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, May 14, 2025 at 4:20 AM gene heskett via Nut-upsuser <<a href="mailto:nut-upsuser@alioth-lists.debian.net">nut-upsuser@alioth-lists.debian.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 5/13/25 21:05, Sam Varshavchik wrote:<br>
> gene heskett via Nut-upsuser writes:<br>
><br>
>> However debians legendary slowness to update things does test my <br>
>> patience at times. The fact that bookworms default nut is 2.8.0 is an <br>
>> example.<br>
><br>
> That sounds familiar. Debian's been shipping very old versions of my <br>
> packages, which was …irritating. I am not being accusatory, I <br>
> understand that it's all volunteer work, and most of the time …there <br>
> was no volunteer. But it was still a problem for me.<br>
><br>
> I solved this problem by boning up, learning how to create deb <br>
> packages, then including a script in my tarballs that create deb <br>
> packages from their own tarballs – very similar to how including a <br>
> package.spec in the tarball allows rpmbuild to build installable rpms <br>
> directly from the tarball: "rpmbuild -ta package-version.tar.bz2", sit <br>
> back, and wait for the binary rpms to be created.<br>
><br>
> As far as I know debuild doesn't have anything comparable to this, but <br>
> what I hacked up came pretty close. The report from the field was that <br>
> non-developers are able to use it. And this solved the "old packages <br>
> in Debian" issue and made it go away, for the most part. I only made <br>
> sure that what I did was not going to interfere with anything a real, <br>
> honest to goodness, Debian or Ubuntu maintainer needs to do, so when <br>
> one shows up, occasionally, from time to time, it stays out of their way.<br>
><br>
> Unfortunately this is not something that works generically, the script <br>
> is tailored specifically to the tarball's contents. But that's the <br>
> general solution to addressing old stuff in Debian or Ubuntu.<br>
<br>
Well i have been in the past, able to build from the tarballs but will <br>
readily admit that at 90 yo, its getting less and less appetizing. <br>
However when 2.8.3 is out, I might give it a shot if I can actually get <br>
Jim's output. Or possibly switch distro's. Debian has about worn me <br>
out. I have a time wasting bug that no one on this ball of rock & water <br>
can duplicate.<br>
<br>
Thanks Sam V.<br>
<br>
><br>
><br>
> _______________________________________________<br>
> Nut-upsuser mailing list<br>
> <a href="mailto:Nut-upsuser@alioth-lists.debian.net" target="_blank">Nut-upsuser@alioth-lists.debian.net</a><br>
> <a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser" rel="noreferrer" target="_blank">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser</a><br>
<br>
Cheers, Gene Heskett, CET.<br>
-- <br>
"There are four boxes to be used in defense of liberty:<br>
soap, ballot, jury, and ammo. Please use in that order."<br>
-Ed Howdershelt (Author, 1940)<br>
If we desire respect for the law, we must first make the law respectable.<br>
- Louis D. Brandeis<br>
<br>
<br>
_______________________________________________<br>
Nut-upsuser mailing list<br>
<a href="mailto:Nut-upsuser@alioth-lists.debian.net" target="_blank">Nut-upsuser@alioth-lists.debian.net</a><br>
<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser" rel="noreferrer" target="_blank">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser</a><br>
</blockquote></div>