As per subject line. Would arches in CC please stabilize sys-power/nut-2.0.3-r1. I've personally tested the APC driver and the USB HIDUPS driver, on both powerpc and x86. It's not really a package that can be src_test()d, so just check that it compiles 100% for you. Feel free to try to set it up for your UPS if you have one.
Arches: please stabilize this package (I don't know if bugzie sent out an email on this before).
ppc64 done, thanks
stable on SPARC
As said on the bug, in x86 compiles and calling the executable file does not report Segmentation fault.
Compiles on ppc, so stable.
Compiles fine on amd64, though I can't say anything towards functionality since I don't have an UPS to test it...
stable on amd64
x86 is done again ^.^
Seems to have broke on my system. I know I can change the owner and permission or run it as root but the package should have something to help configure. At the very least, an einfo to suggest how to go about it as well as some recomendation. When I try to start upsdrv I get: * Starting UPS drivers ... Network UPS Tools - UPS driver controller 2.0.3 Network UPS Tools - Generic UPS driver 1.31 (2.0.3) UPS type: Generic RUPS model Unable to open /dev/ttyS0: Permission denied Current user id: nut (84) Serial port owner: root (0) Serial port group: tty (5) Mode of port: 0660 Things to try: - Use another port (with the right permissions) - Fix the port owner/group or permissions on this port - Run this driver as another user (upsdrvctl -u or 'user=...' in ups.conf). See upsdrvctl(8) and ups.conf(5). Fatal error: unusable configuration Driver failed to start (exit status=1) * Failed to start UPS drivers! [ !! ]
weyhan: put your 'nut' user in the tty group.
weyhan: if you post and expect a response, please remember to add yourself to the CC list.
(In reply to comment #11) > weyhan: if you post and expect a response, please remember to add yourself to > the CC list. Sorry, it was 5am over here when I post. Anyway, no. I have not added nut in my tty group when I hit that error. But my point is that the emerge did not even turn up an einfo to advice user to do so. Besides, I feel that adding nut to tty group should be done in the emerge process. Sorry that I seem like I am looking for support but I'm really saying that the nut ebuild should have handle this correctly.
weyhan: No, it depends entirely on what UPS driver you are using as to what the correct groups for nut are, and this is supplemented by the normal Gentoo documentation as well as the upstream NUT documentation. For a purely remote NUT installation (eg some other machine is monitoring the UPS) nothing is needed. For a driver that uses a serial port, the tty group (or messing with udev rules) is needed. For some USB drivers, udev rules for /dev/bus/usb are needed. For SNMP drivers, nothing is needed. There are other cases as well.
Robin, Okay, I get you're point. But how about a small einfo? In my case, nut was working fine until I've upgraded the system over the weekend and then nut don't work anymore. It would have save me hours trying to figure how to fix it.
what version were you using before? was it pre the addition of a NUT user?
Yes. The exact version was nut-2.0.0
weyhan: I've added a warning and set things up suitably. alpha: please compile-test and mark stable.
Robin, Great work!
Please close. nut-2.0.3-r1 stable on all platforms except alpha & x86-fbsd.
Andrew: no. alpha needs to mark 2.0.3-r1 stable, so that I can remove the old versions without removing the only ones that alpha has marked as stable. alpha: please compile-test and mark stable.
Ok so I just marked sys-power/nut-2.0.4-r1 stable on Alpha as per bug #148013. Sorry for the delay. - ferdy
alpha completed, and this bug is superseeded by stabilization of 2.0.4-r1
