NUT v2.8.2, is it here, is it not?

While trying to set up some semblance of a proper release cadence, as well as hoping to tag a new NUT release at this or that "pretty date" time and again, something urgent kept popping up to delay the release. Still, looking month-to-month, this release is 2 years after v2.8.0, so we're on track to yearlies. Maybe quarterlies would not be impossible - just gotta manage expectations and the number of planned milestones :)

As a fun fact, some development work for this release was done directly on an Android phone (Termux app sufficiently delivers a native-architectured Debian/Linux environment), and the release is being cut from a storm in the Northern (Icy) Ocean, enchanted by the ethereal shine of the Polar lights... Interesting times, indeed...

The NUT v2.8.2 release ties up more loose ends from earlier development branches and forks, complete with warnings clean-up and Windows portability where possible/easy, bringing in nutconf (a C++ library to interact with NUT configs and more, and the frontend tool for it), an interactive CLI installer contributed from a vendor's bundling of NUT, more features for the nut-driver-enumerator (NDE), several improvements for the nut-scanner, as well as refinement, enhancements and bug-fixing for features (and odd regressions) added in the recent releases.

Some user-reported issues between their devices and such drivers as riello_usb and usbhid-ups subdriver for Belkin/Liebert support, were also added. It is always pleasant to note the collaborations which happen online, with NUT community members addressing many issues by themselves.

Much non-functional activity revolved around CI-related improvements, including migration of the NUT CI farm from Fosshost (RIP) to Digital Ocean, and revised build recipes with improved portability (especially for documentation builds).

As usual, for more details, see the NEWS.adoc and UPGRADING.adoc files, or even peruse the ChangeLog document.

The next treat on the menu in a future release can be the remainder of the 42ity fork, such as DMF technology support - it finally passed the new strict quality gates of NUT CI that appeared for v2.8.0 release and have evolved ever since. This work informed many pointed fixes for the upstream project, which are included in this release.

NOTE: The initially posted tarball signature file did not pass checks on some systems and was replaced by one made on a different maintainer workstation after a week.

NUT v2.8.1, now with Windows support (again) 🎃

NUT v2.8.1 release: TLDR version

Generally you can preview the live list of notable changes since 2.8.0 release at https://networkupstools.org/historic/v2.8.1/docs/release-notes.chunked/NUT_Release_Notes.html#_release_notes_for_nut_2_8_1_what_8217_s_new_since_2_8_0 and for things that are expected to impact packaging and upgrades (whether by some possibly breaking disruption, or by adding new ways to automate things more efficiently that the audience could benefit from) - at https://networkupstools.org/historic/v2.8.1/docs/release-notes.chunked/NUT_Upgrading_Notes.html#_changes_from_2_8_0_to_2_8_1 - with such release notes publication also being a recent addition.

NUT for Windows is back!

Older development of NUT for Windows was modernized over the past 15 months or so, and was merged as part of main codebase (in 2022, post-v2.8.0). Still, caveat emptor!

Better read up in comments to #5 and #1611 and #1050 to an extent. The short of it is that syntactically NUT builds pass without warnings, and survive integration tests (upsd data server and some dummy-ups driver setups). The binaries can be executed on the platform, drivers can see physical UPS devices and upsd represents them on the network; deeper integration was not tested much yet.

Builds are doable in linux+mingw (using an older build script to arrange configure options) and in Windows+MSYS2 with plain configure or same ci_build.sh as CI builds on other platforms use to arrange it. Prerequisites are listed in scripts/Windows/README and docs/config-prereqs.txt respectively (or now also actionably wrapped by appveyor.yml). Parts of serial driver codebases are ifdef-ed away.

In particular, "purely native" builds (e.g. with Visual Studio) were not attempted yet, not that I know of. The goal was to have something usable first, so first winners were even two - GCC builds with mingw (on linux and in MSYS2), with ccache recommended for faster iterations, with x86_64 and i686 targets. Probably clang is doable, but was not tried yet. Passing in custom CFLAGS into MSYS2 builds (as pre-set envvars or configure argument) caused issues for that build of gcc itself (somehow became part of path it is trying to build in). There are more variants of standard library to juggle too (UCRT etc.) for portability across Windows releases vs. modernity.

Due to availability/easy-buildability of third-party dependencies, these build scenarios currently have some non-overlapping results (notably libgd/cgi, snmp and neon/xml are known inconsistencies).

USB HID may need more work, possibly installing a low-level driver in OS, to see devices in detail. See one practical success story at #1690 (comment)

Maybe that was solved by predecessors in MSI packaging, not re-investigated yet with recent effort. The need for that research is tracked as #1485

These and other known caveats can be seen in NUT for Windows project as open tickets in https://github.com/orgs/networkupstools/projects/2/views/1 project.

Happy Halloween!

NUT v2.8.0+, now with Windows support

Older development of NUT for Windows was modernized over past months, and now merged as part of main codebase (post-v2.8.0). Caveat emptor!

Better read up in comments to #5 and #1611 and #1050 to an extent. The short of it is that syntactically NUT builds pass without warnings, and survive integration tests (upsd and some dummy-ups setups).

Doable in linux+mingw (using an older build script to arrange configure options) and in Windows+MSYS2 with plain configure or same ci_build.sh as CI builds on other platforms use to arrange it. Prerequisites are listed in scripts/Windows/README and docs/config-prereqs.txt respectively (or now also actionably wrapped by appveyor.yml). Known caveats are in NUT for Windows project as open tickets in https://github.com/orgs/networkupstools/projects/2/views/1 project.

In particular, "purely native" builds (e.g. with Visual Studio) were not attempted yet, not that I know of. The goal was to have something usable first, so first winners were even two - GCC builds with mingw (on linux and in MSYS2), with ccache recommended for faster iterations, with x86_64 and i686 targets. Probably clang is doable, but was not tried yet. Passing in custom CFLAGS into MSYS2 builds (as pre-set envvars or configure argument) caused issues for that build of gcc itself (somehow became part of path it is trying to build in). There are more variants of standard library to juggle too (UCRT etc.) for portability across Windows releases vs. modernity.

Due to availability/easy-buildability of third-party dependencies, these build scenarios currently have some non-overlapping results (notably libgd/cgi, snmp and neon/xml are known inconsistencies).

USB HID may need more work, possibly installing a low-level driver in OS, to see devices in detail. Maybe that was solved by predecessors in MSI packaging, not re-investigated yet with recent effort.

Parts of serial driver codebases are ifdef-ed away.

v2.6.5-8-Windows

Old(!!!) NUT-for-Windows effort recently attempted with (partially) modern dependencies, cross-built on Ubuntu per instructions in code, published more as a proof of concept for progressing on issue #5 than for production use.

NUT v2.8.0 (un-signed)

This is a re-post of the release artifacts to keep download URLs based on original vX.Y.Z git tag pattern, as used by distro recipes, intact. Such URLs got broken after addressing issue #1410, as reported later in issue #1971.

For release details, please see https://github.com/networkupstools/nut/releases/tag/v2.8.0-signed

NUT v2.8.0-rc3

A third and hopefully final rehearsal for a pending NUT release, initially focused on updating sources for the documentation published on the nut-website and API to match the large changes, and also fixing a few bugs noted with the intensified testing after v2.8.0-rc1 and v2.8.0-rc2 - especially some found while integrating the new NIT (NUT Integration Testing) suite.

Welcome NUT-EEE (the Easter Egg Edition, because why not - it sounds cute?) ;)

NUT v2.8.0-rc2

A second rehearsal for a pending NUT release, fixing a few bugs noted with the intensified testing after v2.8.0-rc1, and landing some more old pull requests.

Again, production-like testing on as many platforms as possible (including proposed service management integration for systemd and SMF) would be very welcome!

UPDATE: Attached tarball was re-published due to corruption of initially uploaded one.

NUT v2.8.0 (signed)

After a long and windy trip since the last official release v2.7.4 half a dozen years ago, we the community, contributors and maintainers are proud to announce at last the general availability of NUT v2.8.0!

As always, the new release includes numerous new drivers, sub-drivers, protocols and bug-fixes, with many companies and individuals chipping in with contributions of code.Thanks to everyone involved in making this happen, inspiring the changes, and providing the open-source friendly infrastructure.

This release also culminates a significant effort in improvements of NUT QA and CI, and as a result -- in codebase quality and portability across a decade or two of recent platforms, third-party tools and other dependencies. As a side effect, public API (in headers and libraries) has changed a bit, hence a new semantic "minor" number is claimed for this major body of work.

During this time, the https://networkupstools.org/ web site has changed to a rolling-release model to serve current information to match the evolving codebase. There are now special Sub-sites for historic releases to keep documentation snapshots relevant for users of packages which are typically based on official NUT releases.

We recognize that NUT is an important piece of infrastructure which gets built into all sorts of devices, projects and operating systems -- some of which the team never heard of until they pop up in a question, and others we haven't heard of for years -- so we take a seriously omnivorous stance towards covering many versions and implementations of compiler suites, C/C++ revisions, make programs, shell and other scripted language interpreters, OSes and CPUs, and other similar variables tamed with our new NUT CI farm test matrix dynamically driven by currently registered build agents and their declared capabilities.

Sections in the NEWS and UPGRADING files about changes since last release are several pages long, so would not all be repeated here. A few important highlights for distribution packagers and custom builders follow, however:

• NUT now supports more i2c and modbus devices, as well as libusb-1.0 support as an alternative to earlier libusb-0.1 (so new dependency-based categories of packages for drivers may be due);
• NUT Python modules and scripts (e.g. NUT-Monitor variants) should work with python-2.7 and with python-3.x, so covering historic distro releases as well as new ones (and so your distro can deliver one or both, probably in several packages with different dependencies in the latter case);
• NUT provides revised reference systemd and SMF service unit definitions, including support of drivers wrapped into individual service instances with varying dependencies based on different media required (networked stack, USB stack, etc.), and many daemons include -F option for running "in foreground" to avoid extra forking after one already done by a service framework - you may want to use those in your packaged deliverables;
• NUT newly provides the "nut-driver-enumerator" script and service, which allows it to follow edition of ups.conf and dynamically define+(re)start and stop+undefine service instances for drivers - there are several ways it can be integrated for different use-cases;
• there are several new configuration keywords and CLI options - so while new NUT builds should work with old configs and scripts, the opposite is not necessarily true (old binaries may reject configurations taking advantage of new features);
• there are several new protocol keywords - but old and new NUT daemons (data server and clients) should be able to communicate both ways;
• it is assumed that API/ABI changes may require third-party NUT clients (library consumers of libnutclient, libupsclient, libnutscan... -- their version info was bumped accordingly) to get rebuilt, in order to work with the new NUT release in a stable fashion;
• the dummy-ups driver used in automated testing now processes *.dev filename patterns once and does not loop, like it still does for *.seq and other files (by default);
• USB code is now more strict about logical minimum/maximum ranges for data reported from devices, and some devices were already found to make mistakes - so there is also a mechanism for turning a blind eye to known issues and fix-up such report descriptors to produce intended sane values;
• new documentation page docs/config-prereqs.txt highlights packaged dependencies installable on a large range of platforms to build as much of NUT as possible (incidentally, ones NUT CI farm uses to test every iteration);
• finally, we hope that NUT codebase might be able to cater for everyone "out of the box" (it also simplifies local builds from GitHub sources on any systems, for troubleshooting and checking pre-release enhancements): if you as a packager have to apply patches for your distribution, give it a thought -- whether they address a common issue best solved upstream once and behave similarly for everyone (and conversely, if your platform can do with existing solutions already tracked in the NUT version du-jour). PRs welcome! Or at least Wiki entries to list all the distro efforts for cross-pollination :)

A lot of effort and several rounds of community testing have gone into making sure that all these new features and bug-fixes and addressed warnings did not break anything severely, but... things might happen.

Still, there is always room for improvement and many known efforts that did not make it into this release got queued into the next. Likewise, there are some open issues about device/model/firmware-specific behaviors that are known but were not even addressed - we would always welcome help and PRs from community members with devices, debugging/coding skills, and time to spare.

In any case, we hope the next NUT releases will happen in a more manageable cadence ;)

Managing power can be fun, but mis-managing power can be dangerous. While we hope that new NUT release would not have fallout as spectacular and dramatic as from a certain other power monitoring and management system that failed 36 years ago today, please do take care with your electric experiments, and do secure your installations!

NOTE: After this release was cut, it was found that a late-coming feature did not let dummy-ups build on MacOS. A fix and ways to avoid such mishap from repeating are investigated under issue #1415 and would be part of next NUT release. Until then, you may have to build from master branch.

NUT v2.8.0-rc1

Hello, fellow NUTs!

It is with a [happy] heart that I must proclaim today, that the long reign of NUT v2.7.4 is coming to an end. Its anticipated successor of half a dozen years, release-in-waiting NUT v2.7.5 has also quietly expired, and [won't] be sorely missed. They were survived by the next name in line, NUT v2.8.0(-rc1). Le NUT est mort, long live the NUT!

Along just this leg of the journey, NUT codebase survived at least four separate CI farms and technologies to make its builds easier and more reliable, all while succeeding on a wide range of CPU and OS platforms, ranging from current distros to the dawn of millenium (nearly-immutable appliances and sturdy reliable servers matter too!), as well as multiple generations and implementations of compiler toolkits, "make" and scripted code interpreters involved.

We are grateful to the many freely available projects, services and communities who helped us in particular (maybe unwittingly) and the FOSS ecosystem in general (intentionally), such as (and not limited to) Asciidoc, Autotools and family, BuildBot, CCache, Clang/LLVM, FossHost, GCC, GitHub, Google, illumos, Jenkins, LiberaChat, Proxmox, QEMU, StackExchange, Travis, ZeroMQ... bits here, swathes there - it would have been much harder without the likes of them (and many others).

Advances in compiler code analysis in particular, as is seen on a daily basis with CI non-regression builds across the range of 10 major releases of clang and 7 of gcc, are immense. At times annoying, yes, but they led to a great cleansing of the codebase from questionable code (and indeed some potential bugs). And it was possible to do so in a way that all those regularly tested systems are satisfied, so the codebase stays clean and green and portable as we iterate new contributions, and merged with peace of mind many ports and features from long-awaited branches (such as libusb-1.0+0.1 support finally), or forks (notably 42ity/nut).

Let me take a moment to tender our special thanks from both the maintainer team and countless users of UPS, ePDU, solar panel and similar hardware, to numerous personal and corporate contributors of new drivers and features or fixes for existing ones, as well as to community members who ask and answer questions, and who log github issues with their ideas, experiences or grievances.

As always we would welcome people willing to regularly share their expertise in certain areas and tools (such as solving many practical mysteries around USB), or protocols (more active experts on prolific Qx family would be great for PR reviews), or packaging, service and distro integrations, or HCL/DDL maintenance based on reports trickling in... just about anything!

While we have a lot of features queued to complete or port for the next releases (hopefully with a healthier cadence), we expect to see more feedback by exposing the release, and hope for little fallout from the many changes made while cleaning up the warnings.

Handing over to community last-minute testers, and hereby alerting creative packagers now...

Jim Klimov,
on behalf of the Network UPS Tools Project

v2.7.4

Latest official NUT release... for too long. Another is brewing - just watch the commits-since count!

WARNING: this is a recent (2021) action on GitHub Releases metadata, to "announce" the v2.7.4 tag from 2016, so certain REST API actions can be done with it.

If building NUT from scratch, better take a look at the master branch or one of prospect libusb-1.x support branches. And fingers crossed for a 2.7.5 and beyond soon!..