nut: bump version and do some spring cleaning

[danielfdickinson]

📦 Package Details

Maintainer: @danielfdickinson

Description:

• Ensure consist formatting of initscripts by using shfmt
• Add shellcheck overrides or tweak initscripts as needed
• Bump version to 2.8.5 (latest stable version)
• Move drivers to /usr/libexec/nut instead of /lib/nut as they are executables not libraries, and thus were failing the new SONAME check in CI
• Add a version override for the new CI checks, where appropriate
• Split nut-server initscript for easier review (especially AI-based)
• Refactor nut-server scripts to reduce duplication

2.8.5 adds optional JSON output for upsc (the NUT CLI client) and upscgi (the NUT CGI program), which will be used in future to enhance the LuCI interface.

---

🧪 Run Testing Details

• OpenWrt Version: OpenWrt SNAPSHOT r34340-15342a05bd
• OpenWrt Target/Subtarget: bcm27xx/bcm2709
• OpenWrt Device: Raspberry Pi 2 Model B Rev 1.1
• UPS Device: Tripp-Lite ECO550UPS

---

✅ Formalities

• I have reviewed the CONTRIBUTING.md file for detailed contributing guidelines.

[danielfdickinson]

Looks like tiff-utils is broken - not a NUT issue.

[GeorgeSapkin]

tiff-utils seems to be fine. Either some packages needs version test override or it's this:

• multi-arch-test-build: grep version output even on non-zero exit actions-shared-workflows#112

Look at the ones with error and see if those executables return a valid version, like this one:

• https://github.com/openwrt/packages/actions/runs/25605546906/job/75183164135?pr=29390#step:17:5157

[danielfdickinson]

That is a script, not part of the upstream NUT package. It should not be expected to return the NUT version IMO.

[GeorgeSapkin]

You can add a test-version.sh override script that properly tests versions for each sub-package and for that one does exit 0.

[danielfdickinson]

You can add a test-version.sh override script that properly tests versions for each sub-package and for that one does exit 0.

Is this documented somewhere?

[GeorgeSapkin]

No. It's new and still being worked on.

[danielfdickinson]

No. It's new and still being worked on.

Therefore, since it breaks CI, probably for quite a few packages, could it be made only a warning instead of failing the CI, until it is ready?

@BKPepe @hnyman @mhei @dangowrt

[GeorgeSapkin]

You'll still need an override for packages that can't pass generic checks.

I'm working on this, so I'm not sure it's useful to tag more people.

[danielfdickinson]

Yes, but you have no documentation on what the script should look like, or examples to follow. That needs to be remedied before this is made 'live'.

[GeorgeSapkin]

I don't have write access to the actions repo, so I can't fix things in a timely manner, and it's otherwise impossible for me to test every package for every CI change. I do try to test large swaths of open PRs. But things slip through. Which means there's always a chance something will break. If you disagree with these changes, and unhappy about the lack of the documentation, feel free to open a PR in the actions repo to revert all the recent commits.

Here's an example of the version check override script:

• https://github.com/commodo/packages/blob/15d94e1168f48e1d49a610ea934a69de12d16d34/utils/coreutils/test-version.sh

[danielfdickinson]

@GeorgeSapkin What environment are the binaries in for the multiarch test? There are now drivers that are in /usr/libexec/nut that should be versioned checked (/usr/libexec/nut/<driver> -V) - I've currently got that path, but will that work?

[BKPepe]

since it breaks CI, probably for quite a few packages

Look, I think it’s just expected that things will occasionally break or be in constant flux in the development and master branches. As for the CI/CD being 'broken,' I have a slightly different take. Runtime testing in the CI/CD now provides a lot more info much earlier in the process—you can see exactly what failed and that it tested a wide range of other data. You could say it didn't fail across the board.

I get that seeing a 'failed' status in CI/CD can look a bit intimidating, but it’s better to actually check the error and see if it’s even relevant. At that point, it’s up to the maintainer whether they want to merge it or not. Anyone is welcome to contribute, and kicking up a fuss isn't really ideal. :) It just takes some time, and it’ll be fine again.

The simple truth is, no one just got around to it sooner.

And yeah, it would be nice if GitHub Actions had a 'warning' state. - https://github.com/orgs/community/discussions/11592 But then again, you don't want to use warnings for absolutely everything during runtime testing, because most of the time, they just end up being ignored.

[danielfdickinson]

@BKPepe I think the biggest problem for me, was that this was unannounced (I'm on the announce and devel mailing lists and I had no idea this was coming) and (is) undocumented, when it should have been obvious that it would cause many failures and that contributors would/will need guidance on resolving the resulting breakage.

OTOH I did not realize that GitHub Actions doesn't have a 'warning' state. I think it would be useful to selectively use that during a transition period. Since that doesn't look like it will be implemented by GitHub, that is wishful thinking.

It's not so much intimidating as an abrupt shock. Having a bit of warning or buffer would have done a lot for me to not feel like I was being blindsided.

[BKPepe]

Oh, we could do that, though. It’s true. I’m not subscribed to any mailing lists and I don't use IRC like I used to. Hm...

But I get it. :) You know how it is. It's a path full of surprises, and since it’s a packages feed that core members aren't really interested in, posting it to the 'devel' mailing list feels a bit odd. Maybe it’ll make more sense once it’s in the core repo, but yeah, anyway, I guess we can. After all, some people use GitHub Actions quite extensively for building OpenWrt outside of upstream.

[danielfdickinson]

@GeorgeSapkin Sorry for not handling the shock to my system of the CI changes very well.

[danielfdickinson]

@GeorgeSapkin It looks like the version check overrides are not working as expected and the avahi maintainer is having the same issue, from I can see from the logs.

[GeorgeSapkin]

I'll add treewide PR to add version check overrides. I already have a list with some of the misbehaving packages. Once it's open, you can add more offending packages there.

I'd say if builds pass but version checks fail, PRs should be merged for now.

[danielfdickinson]

@GeorgeSapkin Sounds good. Thank you.

[GeorgeSapkin]

I looked at the logs and the override is failing for a few packages:

• https://github.com/openwrt/packages/actions/runs/25618566609/job/75272856963?pr=29390#step:17:5389

Could it be that the exit code from those executables is non-zero so you need to ignore it in the version check?

[danielfdickinson]

Could it be that the exit code from those executables is non-zero so you need to ignore it in the version check?

Will check. Thank you for looking at this.

[danielfdickinson]

Could it be that the exit code from those executables is non-zero so you need to ignore it in the version check?

@GeorgeSapkin It appears the issue is that I was following the this pattern:

EXEC="${PKG_NAME#nut-}"
...
*)
	"$EXEC" -V 2>&1 | grep -qF "${PKG_VERSION}"

but the executable name(s) for the package are not the same as the package name in some cases.

I am working on updating the affected packages' version checks, but I wonder if the script could get a command line parameter with the name of the executable to be version checked, not just the package name.

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Bumps the OpenWrt nut package to 2.8.5, updates packaging to satisfy newer CI checks, and standardizes/init-script formatting (shfmt/shellcheck), including relocating NUT driver executables to /usr/libexec/nut.

Changes:

• Update NUT to 2.8.5 (reset PKG_RELEASE, update source URL/hash).
• Move driver executables from /lib/nut to /usr/libexec/nut across packaging and init/shutdown scripts.
• Add/adjust shellcheck directives and reformat several init/default scripts.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 9 comments.

Show a summary per file

File	Description
net/nut/Makefile	Version bump + driver path relocation + driver list/description updates + configure path changes
net/nut/files/nutshutdown	Use /usr/libexec/nut driver path during shutdown/killpower
net/nut/files/nut-server.init	Formatting/shellcheck updates + switch driver paths to /usr/libexec/nut
net/nut/files/nut-monitor.init	shellcheck directive change + minor formatting tweaks
net/nut/files/nut-cgi.init	shellcheck directives + formatting + directory creation mode handling tweaks
net/nut/files/nut-sendmail-notify.default	Add shellcheck hints + whitespace/pipe formatting
net/nut/test-version.sh	New CI helper script to validate embedded version strings for subpackages

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[GeorgeSapkin]

I am working on updating the affected packages' version checks, but I wonder if the script could get a command line parameter with the name of the executable to be version checked, not just the package name.

The override (and the manual test) is per-package and not per-executable. So you can chose which executables to test yourself, if any.

[danielfdickinson]

I've lost track of where I am with this. Will close and resubmit once I have chance to clear my head. I had just intended a quick version bump, but Copilot's complaints need more than a quick fix (which were part of the refactor I had intended to do as a separate PR).

[danielg4]

This has a new urgency, because both the master branch and the 25.12 branch now fail to build 2.8.4, since the download fails due to a non-matching SHA256 hash. Compare:
https://github.com/openwrt/packages/blob/master/net/nut/Makefile
https://networkupstools.org/source/2.8/nut-2.8.4.tar.gz.sha256
Not sure why it changed upstream, but a version bump would obviously fix it, at least for the master branch.

EDIT: Sorry, didn't notice #29592

[jimklimov]

Regarding the hash for NUT v2.8.4 (released in August) - as explained later on the mailing list, there was some mismatch between tarballs and signatures published before leaving for vacations, which was only rectified in September. The sets published in github release page and on nut-website now should be the correct ones.

There is an ongoing effort about recipes and scripts "properly" handling multi-digit version components, but for now integers are considered a scarce resource, so there was no re-release with a new number to settle it better.

[danielfdickinson]

@GeorgeSapkin @BKPepe Give the above note from @jimklimov do you want me to issue a hash update (AIUI the OpenWrt download mirror will also need updated if I do that)?