Description of problem: as per https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=58672 Version-Release number of selected component (if applicable): ALL releases of RHEL to date How reproducible: Always. Steps to Reproduce: 1.Either create a message with more lines than a short, or, 2.Create many messages such that the amount of data is greater than a short 3.etc. Actual results: Either bad display of messages, or a fseek() panic, etc. Expected results: Should display mail correctly Additional info: Has been fixed in FC for some time, and the bugfix has been in bugzilla for even longer. The patch in referenced bugzilla works perfectly.
According to ug #58672 patch exists - easy fix. This is the only bug for mailx so far, please feel free to reject it.
Excuse me for my ignorance, but what exactly does 'reject it' mean? Why is it considered acceptable to leave a bug in RHEL4 that has been fixed upstream for years? This has actually bitten us in production and I suppose we could log the job as a support call, but really, why bother with Bugzilla at all then?
bug #58672 notes that this was fixed in 2004, and indeed, it does appear fixed in FC4 and on. This seems like a good candidate for a quarterly update.
The problem is that we have to mediate the amount of change introduced in the already released versions of RHEL which are used in production environments Every change bears the risk of regression and side-effects and also our resources are limited so that we need to prioritize components we change in order to be able to focus on the right problems. The prioritization amongst other factors is based on the severity of the problem, the broadness of its impact, customer issues reported via our support organization and the total number of issues against a specific component (e.g. in this case mailx). The comment about "rejecting" has to be seen in this context: we have no other issues open for mailx in RHEL3, non via support escalation, and we have no other data justifying a high prioritization. So for a regular update release we would not prioritize mailx very high and it probably would be deferred to a later release because components with more critical isues would take priority. In the later release we would then re-prioritize. Especially if there is a number of open issues we would address approve updating the component. Now for the specific case of RHEL3, we are beyond the Full Support and in the Deployment phase of it's life cycle. U8 already was an extention of that phase and now RHEL3 is in transition to the Maintenance phase. So at this poing we are additionally reducing the change to be introduced (http://www.redhat.com/security/updates/) Now we indeed ask our customers to report their production issues via our support organization by phone, email or the support web interface (partly depending on the SLA level) instead of directly filing in Bugzilla. Bugzilla is a development tool, not a support tool. It is correct that Bugzilla plays an important role in our processes and all bugs go via Bugzilla. Red Hat actually is working on making more of the bugs we are working on publicly visible in Bugzilla as they are referenced in the errata. But in order to ensure the right prioritization, customer issues need to come via the support organization. I hope that explains a bit what's going on. I do not see a way we can fix this mailx issue in RHEL 3.9.
One little clarification: we actually ask customers to always report issues via the support organization. - Not only now.
Product Management has reviewed and declined this request. You may appeal this decision by reopening this request.
Errr, okay, that long message is nice for RHEL3. However, this issue also exists in RHEL4, as noted in the comments above. Moving to RHEL4 and reopening.
*** This bug has been marked as a duplicate of 184139 ***
I am astounded by this thread. How is anyone helped by us logging a formal support call for this trivial fix? Will RHEL5 also have this bug when it is released? Does it not bother anyone that this problem is an overflow? (hello!!!!???) How does marking this as a duplicate of the CLOSED Red Hat 7.1(!) bug help to resolve it for RHEL4? Crazy. I don't understand why *anyone* in the public would bother using Bugzilla when the response is, basically, "we can't be bothered". Just astounding. Anyway, I'm off to log a formal support request for a RHEL4 bug that is affecting us reading our mail.
Hmmm. There seems to be an advisory which fixes bug #18413 http://rhn.redhat.com/errata/RHBA-2006-0687.html and this is marked as a duplicate of that. However, that seems to have been only put out as an update for "Other", not as an actual RHEL 4 update -- weird.
Hmm, weird, somehow I ended up at the RedHat 7.1 entry when I clicked the 'duplicate' link instead of the RHEL4 one with the errata referenced. Odd. Anyhow, nice to see it's been/being fixed - even if it hasn't been released officially for RHEL4 yet...