Bug 437558
Summary: | rrdtool-php rrd_update not working right | ||
---|---|---|---|
Product: | [Fedora] Fedora EPEL | Reporter: | Kevin Fenzi <kevin> |
Component: | rrdtool | Assignee: | Jarod Wilson <jarod> |
Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | low | Docs Contact: | |
Priority: | low | ||
Version: | el5 | ||
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2008-04-06 03:54:38 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Kevin Fenzi
2008-03-14 21:16:25 UTC
I seem to recall that I forgot to spin 1.2.27 for epel, and epel is still at 1.2.23 or 1.2.24... Pretty sure the php bits themselves remain unchanged between the two versions, but if you could, try bumping to 1.2.27 and see if it doesn't help... Just submitted 1.2.27 builds for both EL4 and EL5... Those packages give me: error: Failed dependencies: php-api = %{php_apiver} is needed by rrdtool-php-1.2.27-1.el5.i386 On trying to install. ;( If I ignore the failed dep (with --nodeps), they generate the same error as the older ones. ;( (In reply to comment #3) > Those packages give me: > > error: Failed dependencies: > php-api = %{php_apiver} is needed by rrdtool-php-1.2.27-1.el5.i386 > > On trying to install. ;( D'oh. Fixing. > If I ignore the failed dep (with --nodeps), they generate the same error as the > older ones. ;( Damn. I got nothin' right now. We probably need to ping Tobi. Yeah, I poked around with it some more, and it's in the php bindings for sure. Manually running 'rrdtool update ...' with the same args as the php version of rrd_update works fine. So, somewhere the update is picking up a 'update' file instead of the real one. In rrdtool.c.php: argv[0] = "dummy"; argv[1] = estrdup("update"); argv[2] = estrdup(file->value.str.val); argv[3] = estrdup(opt->value.str.val); So it's passing 'dummy update FILE VALUE', perhaps the args to rrd_update have changed? Ok, should we talk with upstream about this one? Can you do that? Or would you like me to try and do so? Or do you have any further ideas? I got nothin', and don't actually use the php bits for anything myself. That. and I've got a fair amount of other things I need to work on this week, so if you could chase this upstream, that would be great. Actually, I really ought to hand this package over to someone else, I don't really use any of the bits period for anything anymore... Filed an upstream ticket: http://oss.oetiker.ch/rrdtool-trac/ticket/150 Which got closed as invalid, as they don't ship any official php bindings. ;( I also just dropped an email to the mailing list upstream... If you have any ideas, please let me know. ;( The following patch (From Sean Reifschneider <jafo>) fixes this for me: *** rrdtool-1.2.27/php4/rrdtool.c.old Fri Apr 4 17:43:53 2008 --- rrdtool-1.2.27/php4/rrdtool.c Fri Apr 4 17:44:26 2008 *************** *** 373,379 **** argv[3] = estrdup(opt->value.str.val); optind = 0; opterr = 0; ! if ( rrd_update(3, &argv[1]) != -1 ) { RETVAL_TRUE; } --- 373,379 ---- argv[3] = estrdup(opt->value.str.val); optind = 0; opterr = 0; ! if ( rrd_update(2, &argv[2]) != -1 ) { RETVAL_TRUE; } So, can you apply the above, and we can close this out? Or would you like me to apply it? Gah... Patched up rawhide... but does this actually impact rawhide, or did I just break rawhide? :) I'll toss it into el5 in a sec. EL5 and EL4 packages building now |