Red Hat Bugzilla – Bug 453408
automake test suite skip condition bug
Last modified: 2013-03-07 10:17:00 EST
Description of problem:
automake SRPM had a missing build dependency
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. rpmbuild SRPM
2. Watch it fail
FAIL on several tests
PASS on those tests
The texinfo-tex package is required (for the tex12dvi command), but is not
marked as a build requirement in the SRPM.
Oops - that should be "texi2dvi", not "tex12dvi". Damn dyslexia :-)
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.
> 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.
> 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.
Created attachment 368215 [details]
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.
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.
> 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
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
> 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, 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,