|Summary:||automake test suite skip condition bug|
|Product:||Red Hat Enterprise Linux 5||Reporter:||Vic <rhbugs>|
|Component:||automake||Assignee:||Pavel Raiskup <praiskup>|
|Status:||CLOSED WONTFIX||QA Contact:||qe-baseos-tools|
|Version:||5.2||CC:||kasal, ovasik, pknirsch|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2013-03-07 12:36:53 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Vic 2008-06-30 13:30:25 UTC
Description of problem: automake SRPM had a missing build dependency Version-Release number of selected component (if applicable): 1.9.6-2.1 How reproducible: Every time Steps to Reproduce: 1. rpmbuild SRPM 2. Watch it fail 3. Actual results: FAIL on several tests Expected results: PASS on those tests Additional info: The texinfo-tex package is required (for the tex12dvi command), but is not marked as a build requirement in the SRPM.
Comment 1 Vic 2008-07-04 14:03:31 UTC
Oops - that should be "texi2dvi", not "tex12dvi". Damn dyslexia :-)
Comment 4 Stepan Kasal 2009-11-03 15:51:04 UTC
I was not able to reproduce the problem. The Automake test suite checks for the prerequisities of each of the test and if they are not met, the test is skipped. I have verified that the mechanism works correctly when I rebuild the automake rpm in current RHEL-5 build tree. Adding more BuildRequires is a good idea, and I'm going to do that in Fedora development. But this enhancement is not justifiable for a RHEL erratum.
Comment 5 Vic 2009-11-04 12:59:24 UTC
> I was not able to reproduce the problem. > > The Automake test suite checks for the prerequisities of each of the test and > if they are not met, the test is skipped. I have verified that the mechanism > works correctly when I rebuild the automake rpm in current RHEL-5 build tree. txinfo3.test requires makeinfo and tex. These are provided by the tetex and texinfo packages reqpectively. texi2dvi is provided by texinfo-tex - it is not explicitly tested by txinfo3.test, and at the date I submitted this bug report - well over a year ago - the texinfo-tex package was not required by either of the two requirements that are actually tested. I have yet to check whether this is still the case, but it remains the fact that even if this dependency has been added to the packaging system (and a scan of the .spec file for the new version of tetex doesn't look encouraging), this is still an implicit dependency. I had a bunch of other tests that failed in a similar fashion, but I did all that work back in June 2008. The machine I was using is long gone, and the log files along with it. > Adding more BuildRequires is a good idea, and I'm going to do that in Fedora > development. But this enhancement is not justifiable for a RHEL erratum. There was an error in the build process. I suspect there still is. What is the point of soliciting feedback when that feedback is simply ignored? I don't think I'll be reporting any more bugs to RH, whatever severity they might be. The turn-around time is simply shocking (16 months for this one!), and the response is more about closing tickets thatn resolving problems. The next bug reports I file will be on public blogs, just like everyone else.
Comment 6 Stepan Kasal 2009-11-09 14:20:06 UTC
> The turn-around time is simply shocking (16 months for this one!), I apologize for that. > txinfo3.test requires makeinfo and tex. [but not texi2dvi that is in a separate package] Indeed, this is a bug in txinfo3.test. It manifests itself only in specific conditions (texinfo and tetex installed, texinfo-tex not) which I was not able to infer from the original description. It became absolutely clear after reading the previous comment. Yes, you are right, the same problem appears in also in other tests. All of these bugs were fixed upstream, in the following releases of GNU Automake. Though it would be possible to work around the bug by adding texinfo-tex to build requires, I prefer backporting the aformentioned fix.
Comment 12 Pavel Raiskup 2013-03-07 12:36:53 UTC
RHEL-5.10 (the next RHEL-5 minor release) is going to be the first production phase 2  release of RHEL-5. Since phase 2 we'll be addressing only security and critical issues. This one issue is just build problem, which is not going to be missed in future rebuild (if any). I'm closing WONTFIX. Pavel  https://access.redhat.com/support/policy/updates/errata/
Comment 13 Vic 2013-03-07 12:59:49 UTC
Are you having a laugh? It's taken nearly five years for anything to happen on this bug. Five years. That's despite me giving the solution when I submitted it, and despite Stepan Kasal claiming to have backported the patch well over two years ago. And now it's a WONTFIX? I wash my hands of the bloody lot of you. Nevermore will I recommend RH. Vic.
Comment 14 Pavel Raiskup 2013-03-07 14:05:10 UTC
> It's taken nearly five years for anything to happen on this bug. Five years. > That's despite me giving the solution when I submitted it, and despite > Stepan Kasal claiming to have backported the patch well over two years ago. Yes, thanks for your cooperation and for your report, it is _always_ appreciated. Sorry I did not say that properly. > And now it's a WONTFIX? I checked the build system logs for this issue and the testsuite always passed. Sorry I haven't not mentioned this before. There seems to be no need to fix this for RHEL5 purposes. Again, there is important to say that this bugzilla is just about automake's build - users may not be affected (just about about building automake). The resolution is WONTFIX because of these reasons. Thank you for taking the time to enter a bug report with us. We appreciate the feedback and look to use reports such as this to guide our efforts at improving our products. That being said, this bug tracking system is not a mechanism for requesting support, and we are not able to guarantee the timeliness or suitability of a resolution. If this issue is critical or in any way time sensitive, please raise a ticket through your regular Red Hat support channels to make certain it receives the proper attention and prioritization to assure a timely resolution. For information on how to contact the Red Hat production support team, please visit: https://www.redhat.com/support/process/production/#howto Thanks, Pavel
Comment 15 Vic 2013-03-07 14:20:07 UTC
> it is _always_ appreciated Five years to get a WONTFIX does not fit the definition of "appreciated". > I checked the build system logs for this issue and the testsuite always passed. And yet if you look at Comment 6, you'll see that it has been seen as a real bug. That comment was made in 2009, and we're now in 2013. It's on the same page you're reading right now. > There seems to be no need to fix this for RHEL5 purposes You've got a situation where the SRPM for a package does not build. You've got a fix that requires a single line to be added to a spec file. Alternatively, you've got a patch purportedly made by a RH engineer to fix it in a slightly different manner. So it's not like there's any actual work needs doing to repair a problem with the software you're shipping. And you reckon there's no need to fix it? *That's* why I consider this a show-stopper attitude. When I submit patches to other distros, I don't get this resistance to correcting a fault. Frankly, I'm horrified that I've got it from RH. Vic.
Comment 16 Pavel Raiskup 2013-03-07 15:17:00 UTC
Vic, thanks again for your bugreport. I'm not the guy who could move with this bug on - I'm not able to set RHEL priorities. As I adviced you before - please raise a ticket through your regular Red Hat support channels. Thanks for your understanding, Pavel