There is finally, after years a new version available for the nut tools: https://github.com/networkupstools/nut/releases/tag/v2.8.0-rc1
RC2 is available: https://github.com/networkupstools/nut/releases/tag/v2.8.0-rc2
RC3 (and probably the last) ist available: https://github.com/networkupstools/nut/releases/tag/v2.8.0-rc3
And finally the 2.8.0 is released: https://github.com/networkupstools/nut/releases/tag/v2.8.0
I get the following error when trying to compile nut-2.8.0: DOC-MAN Generating nutupsdrv.8 a2x: ERROR: "xmllint" --nonet --noout --valid "/var/tmp/portage/sys-power/nut-2.8.0_pre/work/nut-2.8.0/docs/man/tmp/man8.nutupsdrv.8.2077/nutupsdrv.xml" returned non-zero exit status 4 mv: cannot stat './tmp/man8.nutupsdrv.8.2077/nutupsdrv.8': No such file or directory make[2]: *** [Makefile:1646: nutupsdrv.8] Error 1
*** Bug 853829 has been marked as a duplicate of this bug. ***
Also, NUT v2.8.0 added drivers for several new UPS models, including generic_modbus, phoenixcontact_modbus, huawei-ups2000, socomec_jbus, and adelsystem_cbi. However, the use of these drivers requires an external library libmodbus installed and the build option --with-modbus switched on when building NUT. The ebuild should be updated with support of building Modbus drivers.
Created attachment 791084 [details] nut-2.8.0.ebuild proposal -2.7.4 version as used as a starting point -modbus use flag is added due to some new drivers requiring libmodbus to compile -Driver list is updated to match the available drivers -All old patches that did not apply are just dropped -QA issues regarding udev and tmpfiles silenced -One new patch (nut-2.8.0-fix-man-page-generation.patch) is needed to fix man page generation when only some of the drivers are built
Created attachment 791087 [details, diff] The patch needed by the proposed ebuild
Hello Timo, many thanks, looks good for me, tried it on my own overlay, compiled fine. Only in the post section there was 1 error, do not know whats the cause: * Running udev control --reload for reloading rules and databases ... [ ok ] Failed to open 'nut-common.tmpfiles': No such file or directory * The tmpfiles processor exited with a non-zero exit code Beside that, it runs actually and the upgrade went fine. Will leave it on my server :) Ronny
Thanks for testing Ronny! Do you happen to be using systemd on your system? It seem if I git grep tmpfiles in the nut source tree, everything seems to be related systemd. Maybe it should be run only if systemd use flag is in place...? I did open a ticket upstream about the man page generation issue: https://github.com/networkupstools/nut/issues/1467 Let's hope we don't need to patch it in upcoming versions.
tmpfiles should probably be installed unconditionally (as this ebuild tries to do). This line dying: >tmpfiles_process nut-common.tmpfiles ... implies that the issue is it isn't actually being installed.
Hi Timo, i do not use SystemD (i use OpenRC).
I can see that the tmpfiles generation is tied to systemd in the configure script. It doesn't get generated at all unless you have systemd installed. Which is bit odd as the file appears to be there for clearing up state files (it seems). So, I think the only approach is to handle the tmpfiles on systems where systemd is enabled. I'm not sure how we should detect this in ebuild. Do we need to add a use flag for systemd? I don't think that would be a good idea. Can we see it some other way already?
Created attachment 791318 [details] Second revision There is now systemd use flag in the ebuild, which probably should solve the issue that tmpfiles_process fails on systems where systemd is not found. We just don't do the processing if systemd use flag is not present. I think this probably should be fine. This made me think that there might be similar issue with udev rule processing. Are there anyone who might be not using udev and might want to not do udev rule reloading? Ronny, if you could try now does this solve the issue you were having with tmpfiles processing on your system? Thanks.
Hi Timo, compiles fine, no more warnings for the systemd tmpfiles, good work :) From my PoV this can now be commited to portage in testing. Many Thanks, Ronny
Thanks for testing Ronny! The upstream devs are acknowledging the issue I reported and it looks like they will either take my patch as is or in some other form at least. Thus, we should be able to drop the patch once a new upstream version is released. I'll look forward to hear from Gentoo devs whether we still need anything to this ebuild or is it good enough now.
Note the NUT-Monitor client was dropped previously due to requiring Python 2 and GTK 2. I use and like the client, so I ported it to Python 3 and Qt 5. This was included in NUT 2.8.0. There is, however, a bug in icon handling, which needs patching: https://github.com/networkupstools/nut/issues/1567 My overlay has an older pre-release of the port in sys-power/nut-monitor-2.0_pre20220220 - I suggest keeping it in a separate package (no benefit to bundling it?) and just updating it to the official release.
The attached ebuild, while mostly working, does not support USB scanning with nut-scanner. if you enter: nut-scanner -U You get Cannot load USB library (/usr/lib64/libusb-1.0.so) : file not found. USB search disabled.
The usb-scanner thing seems to be caused by nut selft, not because of the ebuild, it seems this would fix it https://github.com/networkupstools/nut/issues/233 So the next release should *hopefully* cover this then. === For me this is also the case with the nut-scanner for usb: # nut-scanner -D -D -D 0.000000 [D2] Looking for lib libusb-1.0.so in directory #0 : /usr/lib64 0.000633 [D2] Candidate path for lib libusb-1.0.so is /usr/lib64/libusb-1.0.so (realpath /usr/lib64/libusb-1.0.so) 0.000660 [D1] Looking for lib libusb-1.0.so, found /usr/lib64/libusb-1.0.so Cannot load USB library (/usr/lib64/libusb-1.0.so) : file not found. USB search disabled. Maybe we could go one here ? or is the nut-scanner USB a blocker ?
