RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 656245 - stropts.h file not present in /usr/include
Summary: stropts.h file not present in /usr/include
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: man-pages-overrides
Version: 6.0
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Peter Schiffer
QA Contact: BaseOS QE - Apps
URL:
Whiteboard:
Depends On:
Blocks: 714073 743047 748554
TreeView+ depends on / blocked
 
Reported: 2010-11-23 10:30 UTC by Nawaz
Modified: 2024-02-12 04:25 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Prior to this update, a manual page for the fattach function was missing. This update adds the fattach(2) manual page.
Clone Of:
: 714073 (view as bug list)
Environment:
Last Closed: 2011-12-06 11:45:56 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 439403 0 low CLOSED /usr/include/stropts.h missing from rawide 2021-02-22 00:41:40 UTC
Red Hat Product Errata RHBA-2011:1571 0 normal SHIPPED_LIVE man-pages-overrides bug fix update 2011-12-06 00:39:05 UTC

Internal Links: 439403

Description Nawaz 2010-11-23 10:30:31 UTC
Description of problem: 
stropts.h file not present in /usr/include


Version-Release number of selected component (if applicable):
RHEL 6.0 GA

How reproducible:
Fresh install of RHEL6.0 on any x86_64 machine


Steps to Reproduce:
1. Search for file in /usr/include
2. 
3.
  
Actual results:
File not found


Expected results:
File should be present.


Additional info:

Comment 2 Daniel Riek 2010-11-29 01:08:41 UTC
This is an omission by purpose.

Citing from comment 1 in bug 439403:
> That's on purpose.  Linux doesn't support STREAMS (many years ago it was
> available as a third party module, but it hasn't worked for years).
> stropts.h is part of a POSIX XSR option, which Linux now, matching reality, 
> says it is not supported.
>
> No idea why graphviz needs it (when all the syscalls are stubbed), but it needs
> fixing (either by adding configure checks, or by using the POSIX recommended
> check - #include <unistd.h>, 
> #if defined _XOPEN_STREAMS && _XOPEN_STREAMS == -1
> /* XSR option is not available, headers, data types etc. may not be 
> available.  */
> #endif
> see http://www.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html
> for more details).

Comment 3 Daniel Riek 2010-11-29 01:09:04 UTC
NOTE: Bugzilla is not a support tool

The Bugzilla interface at bugzilla.redhat.com is used internally by Red
Hat to process changes e.g. to Red Hat Enterprise Linux and related
products, as well as by the Fedora Community to develop the Fedora
Project.

It is publicly available and everyone with an email address is able to
create an account, file bugs, comment on bugs she or he has access to.
Not all bugs are public though and not all issues filed are handled in
the same way: it makes a huge difference who is behind a bug.

Red Hat does monitor Bugzilla entries, and it does review them for
inclusion in errata, etc.

Nevertheless, as noted on the login page, Bugzilla is not a Support
tool. It is an Engineering tool. It is used by Red Hat Engineering to
track issues and product changes, as well as to interact with Egineering
partners and other parties external to Red Hat on a technical level.

So while all changes to Red Hat Enterprise Linux will at a point go
through Bugzilla, this difference has a number of important consequences
for general product issues filed directly through Bugzilla by external
users without any privileged Engineering relationship:

    * Red Hat does NOT guarantee any response time or Service Level
Agreement (SLA) for Bugzilla entries. - A review might happen
immediately or after a time span of any length. The SLAs for Red Hat
Enterprise Linux provided by Red Hat Support can be found at:
https://www.redhat.com/support/policy/sla/production/

    * Not all comments are publicly visible. - Red Hat Support provides
customers with appropriate information excerpts and status updates from
that. Red Hat does not commit to provide detailed explanations, or
guidance in the context of Bugzilla. Therefore for example, Bugzilla
entries might be closed as it seems without any further explanation,
while Red Hat Support actually provides such explanation to customers
filing through the regular support channels.

    * Issues coming through the regular support process, will always be
prioritized higher than issues of similar impact and severity that are
being filed directly through Bugzilla (unless the later get linked to
customer support tickets). This means that they are more likely to be 
addressed and they are more likely to meet inclusion criteria 
consistent with the Red Hat Enterprise Linux life cycle policy:
http://www.redhat.com/security/updates/errata/

    * Work-arounds and Hotfixes if possible and appropriate are provided
by Red Hat Support and through the regular support process. - This means
that even before a permanent fix is made available through RHN, customers
who raised a high severity issue through Red Hat Support, are likely to
receive an interim solution.

Red Hat provides common Bugzilla access in order provide efficient
development community interaction and as much transparency as possible
to our customers. Our Engineers are encouraged to provide non-customer
specific and non-confidential information publicly as often as possible.

So while Red Hat considers issues directly entered into Bugzilla
valuable feedback - may it be as comments to existing Bugzilla entries
or by opening a new one; for customers encountering production issues,
Bugzilla is not the right channel.

Therefore we ask our customers to file requests important for their
production systems via our Support service. Only for those issues, we
can ensure a consistent communication. Information about our production
support process can be found at: http://www.redhat.com/support/process/

Bugzilla can always be used as a supportive channel to that
communication.

Note: If your customer is participating in the Academic program and has
chosen to run a Subscription without support, they consequently have no
access to Red Hat Support and thus no SLA. If you feel that this is
insufficient for your use case, you should consider contacting the Red
Hat Education specialist as described at:
http://www.redhat.com/solutions/education/academic/individual/

Comment 7 Eric Bachalo 2011-05-17 00:02:48 UTC
Changing component to man-pages:

I sugguest The following man-pages should be updated:

fattach(3P), fdetach(3P), getmsg(3P), getpmsg(3P), ioctl(3P), isastream(3P), putmsg(3), putpmsg(3P), stropts.h(0P) 

to link to an UNIMPLEMENTED man page similar to getmsg(2P) i.e. man -s2 getmsg.

Comment 8 Ivana Varekova 2011-06-17 10:14:27 UTC
The manual pages mentioned in comment 7 are in posix part which is the description of posix norm. All of them include a head which tells this is norm description and the the functions could not be implemented on the each version of linux.
All of them except of fattach have a version in section 2 which link to unimplemented.2 manual page.
Thus the only think which can be done from man-pages side is to add fattach.2 as a link to unimplemented.2.

Comment 13 Eliska Slobodova 2011-09-29 11:14:44 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Prior to this update, a manual page for the fattach function was missing. This update adds the fattach(2) manual page.

Comment 14 errata-xmlrpc 2011-12-06 11:45:56 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2011-1571.html

Comment 15 rojiho4305@dixiser.com 2023-10-14 04:05:00 UTC Comment hidden (spam)
Comment 16 Red Hat Bugzilla 2024-02-12 04:25:03 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days


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