Created attachment 576654 [details, diff] rrdtool-1.6.0-allow-line0.patch Sometimes, LINE0 is used as a means to include data that should be listed beneath the graph but not rendered as part of the graph itself. For example, one may wish to report a total, without unnecessarily drawing it over a STACK/AREA graph. As a result of the following commit, rrdtool-1.6.0 breaks the rendering of such graphs: https://github.com/oetiker/rrdtool-1.x/commit/bf7625c A fix for this issue landed in rrdtool-1.7.1: https://github.com/oetiker/rrdtool-1.x/commit/e61e397 Therefore, my request is twofold. Firstly, to bump the 1.6.0 ebuild so as to apply the attached patch. Secondly, to consider 1.7.1 for stabilisation.
(In reply to Kerin Millar from comment #0) > A fix for this issue landed in rrdtool-1.7.1: Thanks for the update! > Therefore, my request is twofold. Firstly, to bump the 1.6.0 ebuild so as to > apply the attached patch. Secondly, to consider 1.7.1 for stabilisation. I don't see the point of fixing both 1.6.0 and stabilising 1.7.1. You could apply the patch through (eapply|epatch)_user locally or unmask 1.7.1 locally for the same effect.
(In reply to Jeroen Roovers from comment #1) > (In reply to Kerin Millar from comment #0) > > A fix for this issue landed in rrdtool-1.7.1: > > Thanks for the update! > > > Therefore, my request is twofold. Firstly, to bump the 1.6.0 ebuild so as to > > apply the attached patch. Secondly, to consider 1.7.1 for stabilisation. > > I don't see the point of fixing both 1.6.0 and stabilising 1.7.1. You could > apply the patch through (eapply|epatch)_user locally or unmask 1.7.1 locally > for the same effect. Indeed, I bumped 1.6.0 in my overlay and I intend to unmask 1.7.1 soon. At the time of writing, my current workload does not permit me the amount of time I would prefer in order to adequately test my munin node for any potential regressions. As such, and until 1.6.0 is dropped from the tree altogether, I thought that patching it might be reasonable. I have no strong feelings on the matter, however.
ok to stabilize the fixed version finally?
I since upgraded from 1.6.0 to 1.7.2 and have experienced no regressions with either munin or the RRDTool::OO module from CPAN. I cannot speak for any other use case, but it looks good to me.
Bump. If a later version isn't going to be stabilised in the near future, I would suggest applying the (trivial) patch to 1.6.0, as was originally suggested.
we can try a newer version I think
Maybe we can CC arches without waiting for the last arch to keyword all :/, at least main arches will get this solved
(In reply to Pacho Ramos from comment #7) > Maybe we can CC arches without waiting for the last arch to keyword all :/, > at least main arches will get this solved Yes, please.
(In reply to Pacho Ramos from comment #7) > Maybe we can CC arches without waiting for the last arch to keyword all :/, > at least main arches will get this solved That should never have stopped you.
As I had privately anticipated, this issue appears to have stalled. Therefore, I am repeating my earlier request to apply the given patch. It is all that will be necessary to close this bug.
arm64 stable
x86 stable
ppc/ppc64 stable
amd64 done
arm stable
sparc stable
hppa stable
Sanity check failed: > net-analyzer/rrdtool-1.6.0-r1 > depend s390 exp profile default/linux/s390/17.0 (2 total) > sys-apps/tcp-wrappers > rdepend s390 exp profile default/linux/s390/17.0 (2 total) > sys-apps/tcp-wrappers > net-analyzer/rrdtool-1.7.2 > depend s390 exp profile default/linux/s390/17.0 (2 total) > sys-apps/tcp-wrappers > rdepend s390 exp profile default/linux/s390/17.0 (2 total) > sys-apps/tcp-wrappers
Closing because the affected versions are no longer available in portage.
Re-opening. Sorry, I didn't notice at first that it had segued into an arch keywording/stabilisation bug.
Unable to check for sanity: > no match for package: =net-analyzer/rrdtool-1.7.2
s390 done all arches done