Bug 453408 - automake test suite skip condition bug
automake test suite skip condition bug
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: automake (Show other bugs)
5.2
All Linux
low Severity low
: rc
: ---
Assigned To: Pavel Raiskup
qe-baseos-tools
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-06-30 09:30 EDT by Vic
Modified: 2013-03-07 10:17 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-03-07 07:36:53 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Backported patch (3.01 KB, patch)
2009-11-09 09:24 EST, Stepan Kasal
no flags Details | Diff

  None (edit)
Description Vic 2008-06-30 09:30:25 EDT
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 10:03:31 EDT
Oops - that should be "texi2dvi", not "tex12dvi". Damn dyslexia :-)
Comment 4 Stepan Kasal 2009-11-03 10:51:04 EST
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 07:59:24 EST
> 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 09:20:06 EST
> 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 7 Stepan Kasal 2009-11-09 09:24:16 EST
Created attachment 368215 [details]
Backported patch
Comment 12 Pavel Raiskup 2013-03-07 07:36:53 EST
RHEL-5.10 (the next RHEL-5 minor release) is going to be the first production
phase 2 [1] 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

[1] https://access.redhat.com/support/policy/updates/errata/
Comment 13 Vic 2013-03-07 07:59:49 EST
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 09:05:10 EST
> 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 09:20:07 EST
> 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 10:17:00 EST
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

Note You need to log in before you can comment on or make changes to this bug.