Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#68764 - [sed] incorrect SELinux information in sed(1) man page

Attached to Project: Arch Linux
Opened by Kian Kasad (kian) - Friday, 27 November 2020, 20:22 GMT
Last edited by Andreas Radke (AndyRTR) - Friday, 04 December 2020, 06:49 GMT
Task Type General Gripe
Category Upstream Bugs
Status Closed
Assigned To Sébastien Luttringer (seblu)
Architecture All
Severity Very Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
In the sed(1) manpage provided by the core/sed package, it contains the line:
This sed program was built with SELinux support. SELinux is enabled on this system.

However, I know that that is not true because the binary itself says SELinux is disabled:
```
$ strings /usr/bin/sed | grep -i selinux
This sed program was built without SELinux support.
```

Additional info:
* package version(s): 4.8-1

Steps to reproduce:
1. run `man 1 sed` to see manpage. Near the bottom, see the line about SELinux.
2. grep for SELinux in `/usr/bin/sed`. The information conflicts with that in the manpage.
This task depends upon

Closed by  Andreas Radke (AndyRTR)
Friday, 04 December 2020, 06:49 GMT
Reason for closing:  Upstream
Additional comments about closing:  It's an upstream issue, I'm going to take the request there instead.
Comment by loqs (loqs) - Friday, 27 November 2020, 21:38 GMT
The sed.1 shipped in the tarball already contains the text for SELinux support enabled. sed.1 is not regenerated if the source is from a tarball.

Does building the package with the attached diff resolve the issue?
Comment by Kian Kasad (kian) - Friday, 27 November 2020, 21:50 GMT
Yes, that diff fixes the error. So it seems like this is an upstream problem and I should discuss this there instead?
Comment by loqs (loqs) - Friday, 27 November 2020, 22:59 GMT
Yes, please discuss the issue with upstream. It can be worked around in packaging as demonstrated but it is not ideal.

Loading...