Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 454083 - [RHEL5] gettext build should rm -f %{_datadir}/info/dir
Summary: [RHEL5] gettext build should rm -f %{_datadir}/info/dir
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: gettext
Version: 5.2
Hardware: All
OS: Linux
low
low
Target Milestone: rc
: ---
Assignee: Jens Petersen
QA Contact: QE Internationalization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-07-04 13:57 UTC by Vic
Modified: 2010-10-18 17:00 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-03-05 01:51:48 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Vic 2008-07-04 13:57:25 UTC
Description of problem:

Building SRPM bombs out with a "file not found" error.

Version-Release number of selected component (if applicable):
0.14.6

How reproducible:
Easily

Steps to Reproduce:
1. Log in as a *non-root* user
2. rpmbuild --rebuild the SRPM
3. Watch the error occur...
  
Actual results:
Build fails trying to rm /usr/share/info/dir

Expected results:
Should build me a shiny new RPM

Additional info:
/sbin/install-info is now set as a prerequisite, and there is an install_info
(note: underscore) define set to point to it - but the makefiles seem to use a
plain install-info command. If /sbin is not in path, this doesn't work.

The workaround for this is to append /sbin to your path when building (and then
it builds just fine) - but this is a bug really...

Comment 1 Jens Petersen 2008-07-07 05:01:31 UTC
This been fixed in Fedora for a while (just with "rm -f").



Comment 2 Jens Petersen 2009-03-05 01:51:48 UTC
While it would be nice to fix, I don't see any plans for a gettext update for RHEL5 currently.

So deferring this for now, sorry.

Comment 3 Vic 2009-03-05 08:01:36 UTC
I am incredulous.

Resolution of this bug won't change shipping binaries - it would just fix a *fault* in the build system.

It's a known fault that's already been fixed in Fedora.

It would take less time to fix it than to defer it.

Yet we're not getting a fix.

Tell me again why I should bother reporting bugs? If RH don't want to be informed of faults in their software, it's easier just to say so.

Comment 4 Jens Petersen 2009-03-06 02:47:14 UTC
(In reply to comment #3)
> Resolution of this bug won't change shipping binaries - it would just fix a
> *fault* in the build system.

True

> It would take less time to fix it than to defer it.

That is not true: the new package would have to go through QA before it could be released.

> Yet we're not getting a fix.

This is a low priority bug which can be fixed if there is ever going to be a gettext errata for RHEL5.
Hence I have closed it "deferred" to take it off my radar for now.

> Tell me again why I should bother reporting bugs? If RH don't want to be
> informed of faults in their software, it's easier just to say so.  

I appreciate the report, but don't feel it is worth making all RHEL5 users update gettext just for this fix.

Comment 5 Jens Petersen 2009-03-06 05:40:06 UTC
Or can you give a bit more context why you want to rebuild gettext without change?


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