Description of problem: Current version in epel7 does not support the "vnstat -5" command Version-Release number of selected component (if applicable): vnstat-1.15-2.el7 How reproducible: 100% Steps to Reproduce: 1. issue the command "vnstat -5" Actual results: [root@microserver ~]# vnstat -5 Unknown parameter "-5". Use --help for help. Expected results: [root@microserver ~]# vnstat -5 enp2s0f0 / 5 minute time rx | tx | total | avg. rate ------------------------+-------------+-------------+--------------- 2022-05-15 14:05 771.14 MiB | 332.20 MiB | 1.08 GiB | 30.85 Mbit/s 14:10 697.37 MiB | 284.79 MiB | 982.16 MiB | 27.46 Mbit/s 14:15 710.00 MiB | 428.20 MiB | 1.11 GiB | 31.83 Mbit/s 14:20 679.08 MiB | 350.90 MiB | 1.01 GiB | 28.80 Mbit/s 14:25 660.61 MiB | 413.66 MiB | 1.05 GiB | 30.04 Mbit/s <snip> 15:55 811.52 MiB | 438.77 MiB | 1.22 GiB | 34.96 Mbit/s 16:00 727.52 MiB | 424.66 MiB | 1.13 GiB | 32.22 Mbit/s ------------------------+-------------+-------------+--------------- Additional info: If the el9 src.rpm is used, ideally the source should be updated to 2.9. Also the section "%package vnstati" needs to have the line "Recommends: %{name} = %{version}-%{release}" removed or conditionally removed if a common spec file is being used for all versions. Lastly the systemd unit file patch needs to be modified to remove the whole "Hardening" section which does not work in 7.x: --- a/examples/systemd/vnstat.service 2022-05-15 08:05:12.053856367 +0100 +++ b/examples/systemd/vnstat.service 2022-05-15 08:05:07.967936194 +0100 @@ -6,31 +6,12 @@ StartLimitBurst=4 [Service] +User=vnstat ExecStart=/usr/sbin/vnstatd -n ExecReload=/bin/kill -HUP $MAINPID Restart=on-failure RestartSec=2 -# Hardening -CapabilityBoundingSet= -LockPersonality=yes -MemoryDenyWriteExecute=yes -NoNewPrivileges=yes -PrivateDevices=yes -PrivateTmp=yes -ProtectClock=yes -ProtectControlGroups=yes -ProtectHome=yes -ProtectKernelLogs=yes -ProtectKernelModules=yes -ProtectKernelTunables=yes -ProtectSystem=strict -ReadWritePaths=/var/lib -RestrictNamespaces=yes -RestrictRealtime=yes -RestrictSUIDSGID=yes -StateDirectory=vnstat - [Install] WantedBy=multi-user.target Alias=vnstatd.service Note also that if the EPEL7 version it updated to 2.9 it takes it ahead of el8 and el9 which are at vnstat-2.6-2.el8 and vnstat-2.8-1.el9 respectively. There is an outstanding bug request to update FC to 2.9 - https://bugzilla.redhat.com/buglist.cgi?bug_status=__open__&component=vnstat&list_id=12608035. If updating EPEL7 to 2.9 is jumping the gun a bit I'd be happy with either 2.6 like el8 or 2.8 like el9.
I'm not the maintainer but just chiming in here with some general packaging advice. The first step should be to update rawhide to 2.9 [0] (can be done with a pull request to [1]). It makes no sense to update the epel7 version to newer than what's in Rawhide, or the other Fedora or EPEL branches for that matter. Generally new versions should go to rawhide first and then backported to stable Fedora and EPEL branches only if it's necessary and appropriate to do so in each branch. It isn't always appropriate depending on the upstream changes. Both Fedora [2] and EPEL [3] have policies about what updates are allowed. Someone needs to review the upstream changes [4] as compared to the current version in each branch. I'm not familiar with the software but a quick skim of the changes shows that several things were removed going from 1.18 to 2.0, so upgrading epel7 from 1.15 to 2.9 would not be allowed by policy. An exception can be requested via the incompatible upgrades policy [5]. [0] bug 2044224 [1] https://src.fedoraproject.org/rpms/vnstat [2] https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ [3] https://docs.fedoraproject.org/en-US/epel/epel-policy-updates/ [4] https://humdi.net/vnstat/CHANGES [5] https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/
Rawhide was updated to 2.9: https://bugzilla.redhat.com/show_bug.cgi?id=2044224
EPEL 7 entered end-of-life (EOL) status on 2024-06-30.\n\nEPEL 7 is no longer maintained, which means that it\nwill not receive any further security or bug fix updates.\n As a result we are closing this bug.