Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 836776 - sys-power/nut-2.8.0 version bump
Summary: sys-power/nut-2.8.0 version bump
Status: UNCONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal enhancement with 4 votes (vote)
Assignee: Robin Johnson
URL:
Whiteboard:
Keywords:
: 853829 (view as bug list)
Depends on:
Blocks:
 
Reported: 2022-04-04 19:55 UTC by Ronny Boesger
Modified: 2023-06-08 16:27 UTC (History)
9 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
nut-2.8.0.ebuild proposal (nut-2.8.0.ebuild,8.91 KB, text/plain)
2022-07-11 18:11 UTC, Timo Kokkonen
Details
The patch needed by the proposed ebuild (nut-2.8.0-fix-man-page-generation.patch,2.07 KB, patch)
2022-07-11 18:12 UTC, Timo Kokkonen
Details | Diff
Second revision (nut-2.8.0.ebuild,9.02 KB, text/plain)
2022-07-13 13:51 UTC, Timo Kokkonen
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ronny Boesger 2022-04-04 19:55:39 UTC
There is finally, after years a new version available for the nut tools: 

https://github.com/networkupstools/nut/releases/tag/v2.8.0-rc1
Comment 1 Ronny Boesger 2022-04-11 05:25:55 UTC
RC2 is available:
https://github.com/networkupstools/nut/releases/tag/v2.8.0-rc2
Comment 2 Ronny Boesger 2022-04-24 19:01:53 UTC
RC3 (and probably the last) ist available:
https://github.com/networkupstools/nut/releases/tag/v2.8.0-rc3
Comment 3 Ronny Boesger 2022-04-27 17:12:14 UTC
And finally the 2.8.0 is released:
https://github.com/networkupstools/nut/releases/tag/v2.8.0
Comment 4 Lars Wendler (Polynomial-C) (RETIRED) gentoo-dev 2022-05-24 11:29:08 UTC
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
Comment 5 Lars Wendler (Polynomial-C) (RETIRED) gentoo-dev 2022-06-23 05:38:48 UTC
*** Bug 853829 has been marked as a duplicate of this bug. ***
Comment 6 Tom Li 2022-07-03 15:28:27 UTC
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.
Comment 7 Timo Kokkonen 2022-07-11 18:11:26 UTC
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
Comment 8 Timo Kokkonen 2022-07-11 18:12:36 UTC
Created attachment 791087 [details, diff]
The patch needed by the proposed ebuild
Comment 9 Ronny Boesger 2022-07-11 19:56:10 UTC
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
Comment 10 Timo Kokkonen 2022-07-12 05:37:50 UTC
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.
Comment 11 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-07-12 05:40:42 UTC
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.
Comment 12 Ronny Boesger 2022-07-12 07:23:19 UTC
Hi Timo, 

i do not use SystemD (i use OpenRC).
Comment 13 Timo Kokkonen 2022-07-12 17:15:20 UTC
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?
Comment 14 Timo Kokkonen 2022-07-13 13:51:12 UTC
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.
Comment 15 Ronny Boesger 2022-07-14 18:56:23 UTC
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
Comment 16 Timo Kokkonen 2022-07-15 05:38:06 UTC
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.
Comment 17 Luke-Jr 2022-08-15 02:41:40 UTC
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.
Comment 18 Karl Hakimian 2022-10-28 17:45:21 UTC
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.
Comment 19 Ronny Boesger 2023-06-07 17:27:57 UTC
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 ?