FEDORA-EPEL-2020-f76f9220f4 created by mhlavink 2 years ago for Fedora EPEL 7
testing

nut updated to 2.7.4

This update has been submitted for testing by mhlavink.

2 years ago

This update's test gating status has been changed to 'waiting'.

2 years ago

This update's test gating status has been changed to 'ignored'.

2 years ago

This update has been pushed to testing.

2 years ago
User Icon orion commented & provided feedback 2 years ago
karma
Error: Package: nut-client-2.7.4-1.el7.x86_64 (epel-testing)
           Requires: systemd-udev

That's one of the reasons I removed that dep :)

Bodhi is disabling automatic push to stable due to negative karma. The maintainer may push manually if they determine that the issue is not severe.

2 years ago

mhlavink edited this update.

New build(s):

  • nut-2.7.4-2.el7

Removed build(s):

  • nut-2.7.4-1.el7

Karma has been reset.

2 years ago

This update has been submitted for testing by mhlavink.

2 years ago
User Icon mhlavink commented & provided feedback 2 years ago

ok, too trusting with MR, -2.el7 is bad too, here comes -3.el7

mhlavink edited this update.

New build(s):

  • nut-2.7.4-3.el7

Removed build(s):

  • nut-2.7.4-2.el7

Karma has been reset.

2 years ago

mhlavink edited this update.

2 years ago

mhlavink edited this update.

2 years ago

This update has been pushed to testing.

2 years ago

This update can be pushed to stable now if the maintainer wishes

2 years ago
User Icon davidep commented & provided feedback a year ago
karma

After the update from nut-2.7.2-4.el7.x86_64 I got many errors like

upsmon[30817]: Poll UPS [UPS@127.0.0.1] failed - Driver not connected
upsd[31441]: Can't connect to UPS [UPS] (apcsmart-UPS): No such file or directory

The /run/nut directory contains only upsmon.pid. I was expecting the "apcsmart-UPS" socket file too...

To recover, I stopped/started the nut-monitor and nut-server individually.

I suspect a conflict in the Systemd unit configuration. The line

ExecStartPre=-/usr/bin/systemd-tmpfiles --create /usr/lib/tmpfiles.d/nut-run.conf

is present in both nut-driver (started by nut-server) and nut-monitor units. According to nut-run.conf contents and the tmpfiles.d man page the "D" flag (Create or empty a directory) could raise the conflict. Maybe "d" is better?

I saw that other RPMs create their directory under /run during the installation, whilst systemd-tmpfiles creates it during the system boot. See also https://fedoraproject.org/wiki/Packaging:Tmpfiles.d

User Icon wolfy commented & provided feedback 6 months ago
karma

Using the client since Dec 2020 without pb. As of yesterday I also have a server. Everything works for me.

BZ#1379382 nut package is missing nut-scanner binary
BZ#1618784 nut-monitor.service references non-existant /etc/tmpfiles.d/nut-run.conf
BZ#1837120 Update nut in EL7

Please login to add feedback.

Metadata
Type
unspecified
Karma
0
Signed
Content Type
RPM
Test Gating
Settings
Unstable by Karma
-3
Stable by Karma
disabled
Stable by Time
disabled
Dates
submitted
2 years ago
in testing
2 years ago
modified
2 years ago
BZ#1379382 nut package is missing nut-scanner binary
0
1
BZ#1618784 nut-monitor.service references non-existant /etc/tmpfiles.d/nut-run.conf
0
1
BZ#1837120 Update nut in EL7
0
1

Automated Test Results