Hide Forgot
Description of problem: Would it be possible to have munin in the epel repository? Version-Release number of selected component (if applicable): munin-2.0.45 Additional info: Munin is a networked resource monitoring tool that can help analyze resource trends and "what just happened to kill our performance?" problems. It is designed to be very plug and play. A default installation provides a lot of graphs with almost no work. Currently I'm running Centos 7 on my nodes and I would like to switch to CentOS 8
This needs to be against the package munin and not epel-release.
I will package Munin to EPEL8 too, but it will take some time. My current plan is that it will based on Munin 3 branch, not 2.
*** Bug 1764798 has been marked as a duplicate of this bug. ***
@Kim can you clarify the following for me: On the munin repository[1] I can see that there is no release for version 3 yet. It seems that they are working on it as there are releases for 2.999.X starting in Oktober 2015 until July/August 2019. The last commit to master was nearly a month ago. This looks like a very slow development speed to me so it might take some more time until an upstream version 3 arrives. Do you plan to wait until then or will you reconsider adding some version 2 of munin to EPEL8 in the mean time? [1] https://github.com/munin-monitoring/munin/releases
Latest version is 2.999.14 and .15 is soon-ish here. Upstream has been using 2.999.x for a long time already, and I've also tested it on RHEL7. So my plan is to package it as 3-prerelease for RHEL8 and next Fedora. There are problems with Munin 2 when considering RHEL8's life time: - Plugins are old (Munin 3 has never versions) - Python-plugins are for Python 2 (Munin 3 has py3), although there are only few - Munin 2 will not receive any new features, it's in bugfix only mode - The major one: Upgrade from Munin 2 to Munin 3 later on won't be straight forward, as Munin 3 web interface has integrated httpd, while Munin 2 is using cgi/cron. Packaging Munin 2 now and then upgrading to Munin 3 after 6-12 months would break a lot of systems, and lot of angry bugs would be opened here. Another option is to maintain both versions in parallel, but I would like to avoid that extra work. There are also some packaging problems in current Munin 2 packages, that can be solved at the same time.
If you want to try, I have build Munin 2 and related Python packages in my private repository for CentOS 8 - http://repo.joomhosting.eu/centos/8/x86_64/ and http://repo.joomhosting.eu/centos/8/SRPMS/ Filip Bartmann
Some bad news: RHEL8/EPEL8 doesn't yet contain all the needed dependencies for Munin 2.999.x or even Munin 2. So I can't yet build either version to EPEL8. Until those are available, I recommend using Filip's private repository. Filip, maybe you could build latest Munin 2.0.51 rpm, as now you have older 2.0.49?
Dotun tommorow I will do it.
During tomorrow I will do it.
So, it will no longer be Munin 2 EPEL the repo? :( I've installed seamlessly from Filip's (thank you guy!) repository and a really few dependencies from here: http://mirror.centos.org/centos/8/PowerTools/x86_64/os/
Munin (3 or 2, but 3 is better) will be included to EPEL 8 when *all* the dependencies are there. By "there" I mean EPEL, not Filip's private repo. You can help by requesting those to be included (open new bugs), or by packaging them by yourself. Filip already has SRPMs, so should be easy.
I've tried to install the munin-node on a CentOS8 system today and it looks like all dependencies are actually present on either EPEL or PowerTools repos (if I'm not mistaken) and the only package that was actually installed from Filip's repository was the munin-node itself. It might be a good time to build the munin-node and move it to epel repository.
FEDORA-EPEL-2020-f9f8233b27 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-f9f8233b27
munin-2.0.54-2.el8 has been pushed to the Fedora EPEL 8 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-f9f8233b27
Not sure if you are looking for feedback (the last couple package-missing-RHEL8 bugs we had they were wanting this type of feedback) We have been running the munin-node part of this package since the 24th on our 7 servers that are at RHEL8. No issues on the client side talking to a RHEL7 2.0.51-1 server.
Nice to hear. You can also go to https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-f9f8233b27 and submit karma +1 there. It still takes 9 more days, or three karmas, before Munin moves from testing to stable.
munin-2.0.54-2.el8 has been pushed to the Fedora EPEL 8 stable repository. If problems still persist, please make note of it in this bug report.
I can successfully see munin-2.0.54-2.el8 in epel now, but it has a dependency for perl-Digest-SHA1 which is not available. On rhel 7 that is available in the rhel-7-server-rpms repo. Using Filip's workaround above I found this package in centospowertools repo. Will this package be added to epel 8 as well?
Munin doesn't require perl-Digest-SHA1 directly. Munin requires perl-Net-SNMP (epel), which requires perl-Digest-SHA1 (powertools). I can't change that. There are two options for you to continue: 1) Open a bug against perl-Digest-SHA1 and request it to be included to epel. 2) Open a bug against perl-Net-SNMP to drop SHA1 requirement. I guess it's there for a reason.
Thank you. Let's start with option 1 for now :) Bug 1803268
The package perl-Digest-SHA1 is in CodeReady Builder and won't be in EPEL. CodeReadyBuilder is a required package set to work with EPEL-8