Debian Package to >=2.8.2 ?

[spacelama]

In the spirit of #1461 and #1433 , no one's been able to get feedback from debian bugs to get 2.8.2 into unstable before the freeze in a month (eg https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1092106 ) and clearly the debian maintainer could do with some help.

Anyone able to offer the maintainer some patches to get the current version into debian before the freeze?

I tried backporting it but couldn't even convince it to compile.

[jimklimov]

I suppose your best bet is contacting people recently active in https://tracker.debian.org/pkg/nut - @bigon, @zeha; there were also commits to https://salsa.debian.org/debian/nut in the past year from @bdrung and @mbiebl (if I am not mistaken about github handle)

[mbiebl]

If nothing happens maintenance wise in Debian, the package will be removed for trixie due to

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1093840

I.e. the package is marked for autoremoval on 08.03.25

[jimklimov]

Thanks for the links... and that seems odd, I understand dropping the fringe client sub-package (indeed broken as of that combo of sources and distro), but whole package? I think people upgrading won't be happy that their UPSes are no longer monitored. Or did I misunderstand, and the bug/autoremoval WAS only about the nut-monitor sub-package (for UI client NUT-Monitor, do not mistake for nut-client with command-line and daemon clients including upsmon daemon for shutdowns)?

Anyhow, for the specific case of telnetlib, there were several layers of fixes (shipping a copy along with NUT, and ultimately replacement with socket library) applied after NUT v2.8.2 release but that can be ported to older code if I don't manage to push NUT v2.8.3 out in time to use out of the box (keep hoping to, got one non-functional but blocker issue to address and it keeps on giving). See #2181 / #2183 and PRs #2501, #2505 and finally #2792 which ripped out the dependency on that library completely; probably as a patch for vanilla 2.8.1/2.8.2 codebase you would want an adapted variant of #2792 change set (some of the PR reverts the changes made in earlier ones to ship a nut_telnetlib.py copy of the library, so that part of the diff would be no-op in code that did not ship it in the first place).

[mbiebl]

Those autoremovals work on a per source package basis, i.e. all binary packages are affected.

[jimklimov]

I see, thanks for the update. I guess the Debian/Ubuntu ecosystem needs someone to step up as an active maintainer for the NUT package, because Arnaud all but retired, and Laurent quietly went offline - I wasn't able to ping him for over a year...

[jimklimov]

One alternative to keep in mind is the long-rolling plan to include more "reference" packaging recipes for different ecosystems in NUT sources (probably under scripts/ or another dedicated directory so as to not conflict with production recipes of distros), and absorb as many hotfixes and patches applied by numerous packages, so that distributions would have less custom work to do... presumably.

Ideally the distro recipes would then devolve to copying the reference recipe and perhaps providing configure script tuning to enable/disable "absorbed" fixes. But I know the real world is not that simple and we won't be able to provide all the nuance fixes as quickly as distros change their policies (e.g. the time64_t related package variants and names), so the real recipes would not be too trivial in fact. But at least it would allow us to introduce new sub-package names consistently across the board as new connection media drivers are introduced (modbus, gpio, sysfs-polling, etc. families recently) instead of dozens of occasional maintainers noticing that a new NUT release brought new gifts like that.

[spacelama]

Given #2792 is merged presumably allowing that RC bug to be closed in debian, and perhaps if the debian maintainer's has a desire to go with a release rather than git master (dunno, seen many packages just take a git master version when it's known that the master branch is a clean tested tree), is a 2.8.3 tag due anytime soon?

Mind you, the existence of a tag isn't sufficient to trigger a maintainer to realise that a build for debian unstable is warranted, given 2.8.2 has been out for a year.

[jimklimov]

Well, one big non-functional blocker before a 2.8.3 release is to address issue #2708 so as to not publish a long-term snapshot with standard names for ups.status values and/or certain NUT variables we decided we do not want in the way they are in code now. So they should be changed to something more sustainable before people who base their work off of official releases would not use something that appears now and disappears in the next release.

But work on that one uncovered some entanglements here and there, so I bite at that problem in small chunks for a few weeks now to get it done with.