nut-server: Fix the other/otherflag functionality

[rpavlik]

Signed-off-by: Rylie Pavlik rylie@ryliepavlik.com

📦 Package Details

Maintainer: @s-hamann, @hnyman, @tofurky, @neheb

Description:
There is an unclear reference to handling unknown config fields for driver config files in the wiki. This adjusts the service script so that they actually work.

• For each value "x" in the per-driver list "other", get the per-driver config variable "other_x", and if it is not empty, write "x = {value of other_x}" to the config file.
• For each value "x" in the per-driver list "otherflag", get the per-driver config variable "otherflag_x", and if it is true, write "x " to the config file.

I think this should be safe to backport, if desired. I tested it on a stable release device.

---

🧪 Run Testing Details

• OpenWrt Version: 24.10.5
• OpenWrt Target/Subtarget: mediatek/filogic
• OpenWrt Device: OpenWrt One

---

✅ Formalities

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

[rpavlik]

Not sure if the second commit is the right way to document that or if there's a better way that's less likely to become desynced.

I backported these commits along with all the others touching this package from master to 24.10 and rebuilt, and the resulting nut packages work well, I don't know the process or policy for backporting changes, but I would recommend it. See https://github.com/rpavlik/openwrt-packages-fork/tree/nut-backport

[danielfdickinson]

@rpavlik This repo's policy is to only make changes on master and and then to cherry-pick applicable changes to stable branches. Therefore, could you rebase on master and force-push this PR?

If the changes are already in master, then, could you go the the head of the the openwrt-24.10 branch and git cherry-pick -x <the-commit> ?

Also, I recommend doing openwrt-25.12 before openwrt-24.10.

Finally, please check the 'formalities' error log. There are a few things that need to be addressed.

Otherwise, LGTM.

[rpavlik]

This branch has always been based on master. I updated, rebased, and pushed again, fixing the commit messages.

[danielfdickinson]

Sorry, I misunderstood because of the run testing on 24.10.

@BKPepe @systemcrash This one looks good to me.

[BKPepe]

Please bump PKG_RELEASE in the Makefile.

[danielfdickinson]

Both commits fail these checks:

[fail] Commit subject must start with a lower-case word after the prefix
[fail] Commit message must exist

[systemcrash]

Yeah, get those commit messages fixed.

Also, while you're there, I suppose you could add support for shutdown_delay and usd and upstype. I think something in build_driver_config should do it.

[rpavlik]

OK, I bumped PKG_RELEASE and adjusted commit messages. I did not make other changes, to avoid excess conflict with other in-progress nut-related PRs.

[danielfdickinson]

@rpavlik I noticed you still don't have any commit message in one of the commits, and only a notice about PKG_RELEASE bump in the other. This will not pass formalities test.

Since the PR text in the original PR description does not get added to the git history and lives only on GitHub, perhaps you could use the PR description in the appropriate parts of your commits?

Commits should be able to stand alone and for a reasonably competent reader to understand what is going on from only the git log and diff (and full files).