Description of problem: /usr/include/php/main/streams/php_stream_filter_api.h:65: error: comma at end of enumerator list --- snipp --- typedef enum { PSFS_ERR_FATAL, /* error in data stream */ PSFS_FEED_ME, /* filter needs more data; stop processing chain until more is available */ PSFS_PASS_ON, /* filter generated output buckets; pass them on to next in chain */ } php_stream_filter_status_t; --- snapp --- That tiny mistake seems to avoid that we can ship Zarafa in EPEL 5. Remove the last comma, http://forums.zarafa.com/viewtopic.php?f=9&t=1002&start=0#p13748 - and building works. Version-Release number of selected component (if applicable): php-devel-5.1.6-23.2.el5_3 How reproducible: Everytime if you try to build Zarafa on Red Hat Enterprise Linux 5. Actual results: /usr/include/php/main/streams/php_stream_filter_api.h:65: error: comma at end of enumerator list Expected results: No error and working stuff...
Thanks for the report.
Joe, do we have a serious chance to get a fix simply pushed out with the next PHP update for RHEL 5 (e.g. with the next PHP security and/or bugfix update)? As it's really a trivial fix, we maybe don't need to escalate that the big way via Red Hat Release Engineering etc.?
I've nominated the bug for inclusion in the next bug fix update - I can't say whether that'll be RHEL 5.5 or later. It might be possible to include the fix in a security update in the mean time, I will bear this in mind; no guarantees though.
As a customer, I would appreciate a little more certainty before this is going to take a year to get fixed (e.g., by the time 5.6 hits).
I've made test packages available which should fix this issue. These packages are unsupported, have not been through the standard Red Hat QA process, and are not recommended for use on production systems. http://people.redhat.com/~jorton/Tikanga-php/ Use of these packages may prevent you from (automatically) upgrading to any asynchronous security errata which are issued before the release of RHEL 5.5 due to version mismatches. Please record any feedback on use of these test packages (positive or negative!) on this bug report.
*** Bug 564307 has been marked as a duplicate of this bug. ***
Is this the way redhat.com take care of its packages? A known and simple-to-fix bug, and the package just stay *BROKEN* until next release? This is my first contact with RedHat and it's so disappointing... Almost 4 months since bug was reported and reporter got a "I will bear this in mind; no guarantees though.", what's the concept of "stability" for you guys?
Come on: - this effects only very few users - it is *easily* worked around - it does not affect operation of php *at all* This has nothing to do with stability or security, no need to push it in an errata update, really.
Renato - I'm sorry you are disappointed. We generally do not push bug fixes out in security updates unless they are of high priority, so I still cannot make any promises that will happen. If this bug is particularly severe for you (or anybody else commenting here), I strongly recommend that you contact Red Hat Support in the first instance. Prioritisation is in the main based on customer feedback via Support. Otherwise; see comment 7 for details of the test packages which are available.
(In reply to comment #13) > Renato - I'm sorry you are disappointed. We generally do not push bug fixes > out in security updates unless they are of high priority, so I still cannot > make any promises that will happen. > > If this bug is particularly severe for you (or anybody else commenting here), I > strongly recommend that you contact Red Hat Support in the first instance. > Prioritisation is in the main based on customer feedback via Support. > > Otherwise; see comment 7 for details of the test packages which are available. I'm sorry to make noise, it's just my concept is different than yours. After 10 years involved with FreeBSD project, i'm just familiar with its concepts. There when we have a problem, it doesn't matter if it affects 1 ore a million of users, what matter is "it affects the operating system", and we don't want an operating system with problems (small or big ones). Since things here follow a more Microsoft-like way, you'll release the fix when you want to do. I just needed to show my POV. But based on this, i'll start to use CentOS instead of paying to use RHEL, CentOS community seem to be fast responsive in this cases and i don't need to pay ;) About the package, i won't use a non-official rpm, but thanks anyway.
(In reply to comment #12) > Come on: > - this effects only very few users > - it is *easily* worked around > - it does not affect operation of php *at all* > This has nothing to do with stability or security, no need to push it in an > errata update, really. Sorry about the noise, i'll back to my cave. :)
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2010-0241.html